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This  document 

This  is  the  current  version  of  the  Z  Standard  being  developed  as  a  BSI  and  ISO  standard.  It  is  the 
Working  Draft  (WD)  of  the  Z  Standards  Panel,  BSI  Panel  IST/5/-/19/2:  Z  Notation),  ISO  Panel 
SC22/WG19  (Rapporteur  Group  for  Z). 


Document  status 

Some  sections  of  this  document  have  been  revised  and  others  are  under  review.  As  a  consequence,  this 
version  of  the  standard  is  neither  complete  nor  internally  consistent.  It  has  been  prepared  and  given 
limited  distribution  in  this  form  so  that  those  working  on  its  revision  can  provide  commments  for  its 
improvement. 


Comments  on  this  document 

Comments  may  be  sent  to 

John  Nicholls,  Convener  Z  Standards  Panel 

Oxford  University  Computing  Laboratory 

Programming  Research  Group 

Wolfson  Building 

Parks  Road,  Oxford  0X1  3QD 

United  Kingdom. 
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Z  was  originally  developed  as  a  specification  notation  for  preparing  formal  descriptions  of  systems, 
without  necessarily  indicating  how  they  will  be  implemented.  This  section  includes  a  description  of  the 
aims  and  objectives  of  formal  specification  notations,  with  special  reference  to  Z.  The  design  principles 
used  in  the  development  of  the  Z  standard  are  described. 


0.1  Notations  for  system  description 

It  is  widely  acknowledged  that  natural  languages  and  similar  informal  notations  have  many  disad¬ 
vantages  when  used  for  writing  technical  descriptions.  In  using  such  languages  it  is  difiicult  to  write 
specifications  with  the  required  precision,  clarity  and  economy  of  expression  and  to  transform  them 
systematically  and  reliably  into  code  or  hardware.  Furthermore,  it  is  impossible  to  carry  out  formal 
mathematical  reasoning  about  informally  written  descriptions. 

In  contrast,  specifications  written  in  formal  notations  can  be  made  precise  and  clear.  Inference  rules 
derived  from  their  mathematical  foundations  enable  designers  to  carry  out  mathematical  reasoning  and 
construct  proofs  relating  to  the  properties  of  system  descriptions. 

The  advantages  of  formal  notations  were  recognised  from  an  early  stage  in  the  history  of  computing, 
although  it  has  taken  considerable  time  for  their  practical  application  to  become  established.  Many  of 
the  early  large-scale  applications  of  formal  notation  were  for  the  specification  of  programming  languages; 
formal  descriptions  of  syntax  are  now  widespread  and  for  some  languages  there  are  formal  descriptions 
of  semantics. 

Formal  notations  are  now  being  used  in  a  wide  and  expanding  variety  of  environments,  especially  in  key 
areas  where  the  integrity  of  systems  is  critical,  or  where  there  is  high  intensity  of  use.  For  a  discussion 
of  domains  of  application  for  formal  methods,  see  [19]. 

Examples  of  the  effective  use  of  formal  specification  notations  axe  found  in  the  following  areas: 


safety  critical  systems 
security  systems 
the  definition  of  standards 
hardware  development 
operating  systems 
transaction  processing  systems 
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Descriptions  of  case  studies  from  these  and  other  application  areas  for  Z  are  listed  in  a  Z  Bibliography 
by  Bowen  [2]. 

0.2  Objectives  of  a  specification  notation 

The  objectives  of  a  formal  specification  notation  are  to  assist  in  the  production  of  descriptions  that 
are  complete,  consistent  and  unambiguous.  To  achieve  these  objectives,  a  formal  specification  notation 
needs  to  be: 

usable  by  those  who  read  and  write  formal  documents; 

expressive,  so  that  it  can  be  used  for  a  wide  range  of  applications; 

precise,  so  that  it  is  possible  to  write  descriptions  that  mean  exactly  what  is  intended; 

given  a  mathematically  sound  meaning,  since  mathematical  reasoning  may  be  used  in  the  devel¬ 
opment  process; 

suitable  for  defining  sufficiently  abstract  models  of  systems  that  specifications  do  not  need  to 
contain  unnecessary  implementation  details. 

0.3  Characteristics  of  Z 

A  central  part  of  Z  is  taken  from  the  mathematics  of  set  theory  and  first  order  predicate  calculus.  For 
the  purposes  of  system  description  additions  have  been  made  to  conventional  mathematics,  including: 


a  type  system  which  requires  each  variable  to  be  associated  with  a  declared  type.  The  ability  to 
type-check  a  specification  helps  in  assuring  that  it  is  accurate  and  consistent; 

the  Z  schema  notation,  which  provides  a  technique  for  grouping  together  and  re-using  common 
forms; 

a  deductive  system  which  supports  reasoning  about  Z  specifications. 


In  addition,  the  following  have  been  developed  to  help  in  the  pragmatic  use  of  Z  in  development  projects: 

the  capability  for  writing  explanatory  text  as  an  integral  part  of  a  Z  document. 

the  inclusion  within  the  standard  of  an  agreed  method  of  representing  text  in  computers  and 
transmitting  it. 


0.4  Design  principles 

The  following  design  principles  have  been  used  in  the  development  of  the  standard  and  are  based  on 
those  used,  explicitly  or  implicitly,  in  the  original  design  of  Z. 
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0.5  Aims  of  standardisation 


Basis  in  mathematics.  Z  is  based  on  a  central  core  of  mathematics  and  uses  accepted  mathematical 
concepts  and  notation.  In  addition,  there  are  means  of  defining  and  checking  the  types  of  Z  elements 
and,  by  means  of  the  Z  schema.,  for  structuring  specifications. 


Utility.  All  parts  of  Z  included  in  the  standard  will  have  been  shown  to  contribute  to  the  main 
objectives  of  Z  and  will  have  been  used  in  significant  case  studies  or  development  projects. 


Simplicity.  There  is  an  objective  to  keep  the  Z  notation  as  simple  as  possible,  consistent  with  its 
overall  objectives. 

0.5  Aims  of  standardisation 

The  Z  standard  supports  the  following  general  aims  of  standardisation  as  listed  in  the  British  Standards 
Institution  Standard  for  Standards  [5]: 

provision  of  a  medium  for  communication  and  interchangeability; 

support  for  the  economic  production  of  standardised  products  and  services; 

the  establishment  of  means  for  ensuring  consistent  quality  and  fitness  for  purpose  of  goods  and 
services; 

promotion  of  international  trade. 


0.6  Validation  of  the  standard 

In  order  to  validate  the  standard,  it  is  necessary  to  ensure  that  it  is  is  appropriate,  consistent  and 
complete,  and  is  in  accordance  with  the  general  understanding  of  the  Z  notation.  In  order  to  achieve 
this,  the  following  steps  have  been  taken: 

existing  descriptions  of  the  notation  have  been  used  as  a  basis  for  the  document; 

alternative  concepts  and  notations  have  been  proposed  where  existing  ones  were  considered  defi¬ 
cient; 

the  standard  is  being  reviewed  by  the  Z  Standards  Review  Committee.,  which  includes  experts  in 
formal  methods,  users  and  tool  makers; 

the  standard  is  being  reviewed  by  the  ZIP  tools  project  to  confirm  that  it  can  be  supported  by 
tools; 

the  mathematical  part  of  the  standard  is  being  checked  for  soundness. 
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The  Z  standard  defines  the  representation,  structure  and  meaning  of  the  formal  part  of  specifications 
written  in  the  Z  notation. 

In  addition  to  defining  the  formal  part  of  the  Z  notation,  the  Z  standard  defines: 

a  Library  or  Toolkit  of  mathematical  functions  for  use  in  writing  Z  specifications; 

an  Interchange  Format  for  Z  documents  that  enables  them  to  be  prepared,  stored  and  transmitted 
within  computer  networks; 

a  deductive  system  for  formal  reasoning  about  Z  specifications. 

A  Z  document  may  contain  both  formal  and  informal  text.  The  lexis  of  the  standard  does  not  define  how 
the  formal  and  informal  parts  are  delimited;  this  is  defined  in  the  Interchange  Format.  The  Interchange 
Format  does  not  define  the  structure  of  the  informal  part  of  a  Z  document. 

The  standard  does  not  define  a  method  of  using  Z. 

□ 
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Notes  on  this  section  of  the  Z  Standard 

Section  title:  Normative  references 
Section  editor:  John  Nicholls 
Source  file:  normref.tex 
Most  recent  update:  29th  June  1995 
Formatted:  3rd  July  1995 


BSI6154  BSI  Standard  BS  6154,  Method  of  defining  syntactic  metalanguage^  British  Standards 
Institution,  1981. 

IS08879  ISO  (International  Organization  for  Standardization),  ISO  8879-1986  (E)  Information 
Processing  -  Text  and  Office  systems  -  Standard  Generalized  Markup  Language  (SGML ), 
Geneva:  ISO,  1986. 


□ 
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Notes  on  this  section  of  the  Z  Standard 

Section  title:  Conformity 
Section  editor:  John  Nicholls 
Source  file:  conform.tex 
Most  recent  update:  16  January  1995 
Formatted:  3rd  July  1995 


A  specification  conforms  to  the  standard  for  the  Z  notation  if  and  only  if  the  formal  text  is  written  in 
accordance  with  the  syntax  rules  and  is  well  typed. 

A  deductive  system  for  Z  conforms  to  the  standard  if  and  only  if  its  rules  are  sound  with  respect  to  the 
semantics. 

□ 
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Notes  on  this  section  of  the  Z  Standard 

Section  title:  Semantic  metalanguage 
Section  editor:  Randolph  Johnson 

Contributions  by:  Stephen  Brien,  Randolph  Johnson,  John  Nicholls,  Jim 
Woodcock,  ...  (others  to  be  added) 

Updated  by:  Randolph  Johnson 
Source  file:  math.tex 
Most  recent  update:  29th  June  1995 
Formatted:  3rd  July  1995 


4.1  Introduction 

This  is  the  first  of  two  chapters  describing  the  mathematical  framework  used  in  the  definition  of  Z.  The 
chapter  includes: 

the  names  of  metalanguage  symbols; 
the  forms  in  which  they  are  used; 
descriptions  of  their  meaning. 


Many  of  the  symbols  used  in  this  chapter  are  derived  from  conventional  mathematics  and  axe  defined 
informally.  Throughout  the  standard,  the  mathematical  treatment  is  based  on  Zermelo-Praenkel  (ZF) 
set  theory.  An  introduction  to  ZF  theory  can  be  found  in  text  books  such  as  Enderton  [7]  or  Hamilton 
[10], 

In  addition  to  conventional  mathematical  symbols,  special  symbols  are  introduced  which  allow  concise 
semantic  definitions  to  be  written.  Where  these  have  meanings  similar  to  those  of  Z,  Z~like  symbols  are 
used.  Definitions  of  new  symbols  are  given  in  terms  of  basic  symbols  (or  other  new  symbols). 

Note  that,  although  symbols  similar  to  those  of  Z  axe  used,  the  semantic  metalanguage  is  not  Z  but 
mathematics  based  on  classical  (i.e.  untyped)  set  theory. 


Naming  conventions.  The  following  naming  conventions  axe  used: 

upper-case  letters  A,R,  C  (sometimes  with  subscripts)  denote  sets; 
upper-case  letters  R^S^T  (sometimes  with  subscripts)  denote  relations; 

lower-case  letters  a,  6,  c  (sometimes  with  subscripts)  denote  members  of  sets  (which  may  also  be  sets 
themselves). 
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Commuting  diagrams.  In  several  of  the  following  descriptions  commuting  diagrams  are  used  to 
illustrate  relationships  between  the  set  constructors  being  defined.  Commuting  diagrams  are  graphs 
whose  nodes  are  labelled  with  sets.  Nodes  are  connected  by  arrows,  each  arrow  being  labelled  with  a 
relation  between  the  sets  at  each  end.  A  diagram  is  said  to  commute  when  any  two  composed  routes 
between  nodes  yield  the  same  result. 


Elision  An  expression  such  as  ai,...,a„  indicates  that  intermediate  members  in  the  finite  list  are 
elided.  Whenever  such  an  expression  is  used,  the  minimum  value  that  n  is  allowed  to  take  (usually  0  or 
1)  will  be  stated.  An  expression  such  as  U  U . . .  indicates  that  all  (finite)  values  of  the  superscript 
are  to  be  included. 

4.2  Definitions  and  declarations 

Variables  and  notations  are  introduced  and  named  as  follows: 

Table  1:  Declarations  and  definitions 


Name 

Symbol 

Example 

Description 

declaration 

a  :  A 

a  is  declared  to  be  a  member  of  the  set  A 

definition 

= 

li> 

A  is  defined  as  B 

Note;  A  declaration  of  a  in  the  form  a  :  A  introduces  the  object  a  and  states  that  it  is  a 
member  of  the  set  A.  Care  has  been  taken  to  ensure  that  when  such  a  declaration  is  used, 
the  set  A  is  non-empty. 
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4.3  Sets 

The  following  sets  are  predefined: 


Table  2:  Predefined  sets 


Name 

Form 

Description 

empty  set 

0 

the  set  having  no  members 

integers 

Z 

1  ...,-2,-l,0,l,2,... 

strings 

S 

the  set  of  all  finite  strings  of  characters 

Relationships  between  sets  and  their  members  are  written  as  follows: 


Table  3:  Relationships  between  sets  and  members 


Name 

Form 

Description 

membership 

d  ^  A 

a  is  a  member  of  A 

subset 

ACB 

-4  is  a  subset  of  B  i.e.  all  members  of  A  are 
members  of  B 

equality 

A  =  B 

sets  A  and  B  are  equal  i.e.  A  and  B  have  the 
same  members 

Z  Notation  Version  1.1  30th  June  1995 


9 


4  SEMANTIC  METALANGUA GE 


4.3.1  Set  constructors 

The  following  set  constructors  define  sets  constructed  from  elements  or  from  other  sets: 


Table  4:  Set  constructors 


Name 

Form 

Description 

set  extension 

{ ai , , . .  ,  On  } 

the  set  comprising  ui, . . . ,  Uni  if  n  =  0,  the 
set  is  the  empty  set;  if  n  =  1,  the  set  is  a 
singleton  set 

union 

A\JB 

the  set  comprising  all  the  members  of  A  and 
all  the  members  of  B 

intersection 

AnB 

the  set  comprising  the  members  common  to  A 
and  B 

set  difference 

A\B 

the  set  comprising  the  members  of  A  that  are 
not  members  of  B 

power  set 

FA 

the  set  of  all  subsets  of  A 

finite  power  set 

¥A 

the  set  of  all  finite  subsets  of  A 
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4.4  Tuples  and  products 

The  following  constructors  define  tuples  and  products: 


Table  5:  Tuples  and  products 


Name 

Form 

Definition 

tuple 

(oi, . . . ,  a„) 

ordered  list  of  the  elements  oi, . . . ,  o„, 

where  n  >  1 

Caxtesian  product 

i4i  X  ...  X 

the  set  of  tuples  (oi, . . . ,  o„)  such  that 

fli  e  Ax  and  . . .  and  o„  e 

enumerated  product 

A^ 

the  set  of  tuples  (oi, . . . ,  a„)  such  that 

ai,---,aneA 

iterated  product 

U  U  U  ... 

Note:  It  is  important  in  the  metalanguage  that  the  sets  form  a  disjoint 

collection.  Under  the  most  common  construction  of  tuples,  this  need  not  be  the  case. 
However,  it  is  true  if,  for  example,  we  view  a  tuple  as  a  finite  sequence  so  that  (ai, . . . ,  a„) 
is  a  function  firom  {1, 2, ...,  n}  into  i4. 
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4.5  Relations 

The  following  are  defined: 


Table  6:  Relations 


Name 

Form 

Definition 

relations 

A*-^  B 

P(^  X  B) 

identity  relation 

Ia 

(a^b)  e  Ia  <=>  a  =  6  A  a  €  -4 

domain 

domiZ 

a  €  dom R  Bb  •  {a,b)  e  R 

range 

raniZ 

b  G  ran  R  3  a  •  {a,  b)  E  R 

converse 

R-^ 

(a,b)ER~^  ^  (b,a)eR 

composition 

R  5  S 

(a,b)  eR°,  S  ^ 

B  c  •  (a,  c)  6  R  A  (c,  b)  e  S 

range  restriction 

Rt>  A 

R  i  Ia 

range  anti-restriction 

R^  A 

R  t>  (rani?  \  A) 

domain  restriction 

A<R 

Ia°jR 

domain  anti-restriction 

A  R 

(dom  i?  \  j4)  <  i? 

Note:  The  composition  operator  binds  more  tightly  than  the  set  constructors. 
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4.6  Functions 

A  function  is  a  relation  with  the  property  that  to  each  element  in  its  domain  there  corresponds  exactly 
one  element  in  its  range,  ^ 


Table  7:  Functions 


Name 

Form 

Description  or  definition 

partial  functions 

A-h^B 

the  set  of  functions  from  A  into  B  whose  do¬ 
mains  are  subsets  of  A 

total  functions 

A—^B 

the  set  of  functions  from  A  into  B  whose  do¬ 
mains  are  the  whole  of  A 

total  injections 

A>-^B 

the  set  of  total  functions  from  A  into  B  which 
are  one-to-one 

total  surjections 

A-^  B 

the  set  of  total  functions  from  A  into  B  whose 
ranges  are  B 

bijections 

Ay^  B 

A^  B  n  A-^  B 

finite  partial  functions 

A-tt^  B 

A-h-5  n  F(A  X  5) 

Table  8:  Function  constructors 


Name 

Form 

Description  or  definition 

constant  function 

maps  all  members  in  the  set  A  to  o 

{b,a)  e  -^4-  b  eA 

relational  image 

HR) 

iA,B)e^{R)  B  =  ra,n{A<]R) 

singleton  image 

Hr) 

{a,B)e^{R)  44-  5  =  ran({a}  <  i?) 

Note:  The  subscript  A  may  be  omitted  if  the  domain  can  be  determined  from  the  context. 


In  the  remainder  of  this  section,  the  term  function,  when  not  otherwise  specified,  is  taken  to  mean 
partial  function. 
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4.7  Set  constructors  as  relations 

Membership,  union,  intersection  etc.  are  not  sets,  and  therefore,  a  fortiori,  not  relations.  However,  the 
restriction  of  any  of  these  to  the  members  or  subsets  etc.  of  a  particular  set  A,  does  indeed  yield  a 
relation.  In  general,  the  relation  determined,  e.g.,  by  the  membership  function,  will  depend  on  the  set 
A;  however,  it  is  convenient  to  use  a  notation  which  supresses  this  dependence  when  A  is  clear  from  the 
context  of  use.  The  notations  used  are  defined  in  the  following  table. 


Table  9:  Set  constructors  defined  as  relations 


Name 

Symbol 

Domain 

Range 

Definition 

union 

(U) 

(P4)2 

FA 

((ai,  02),  6)  €  (U)  4^  6  =  tti  U  02 

intersection 

(n) 

(P4)2 

FA 

((ffli,  02),  i»)  e  (n)  44  6  =  fli  n 

set  difference 

(\) 

(Pyl)2 

FA 

((ai,  “2),  b)  e  (\)  44  b  =  ai  \ 

containment 

(2) 

Pyl 

FA 

{a,b)  e  (2)  ^  be  a 

member 

0) 

P^ 

A 

(fl,  b)  G  (3)  ^  b  G  a 

singleton  set 

{-} 

A 

FA 

(a,  b)  G  {— }  ^  b  =  {a} 

tuple  set 

{•■} 

A+ 

FA 

((ai,...,o„),6)  €  {..}  ^ 

6  =  { fli , . . . ,  dfi  )• 

power 

(P) 

FA 

PPyl 

(a,  6)  e  (P)  b  =  Fa 

relational  override 

(®) 

{A  ^  5)2 

A<—>  B 

((5i,52),5)e(©)  44. 

S  =  (dom52  <  Ri)  U  R2 

Cartesian  product 

(X) 

(Pyl)+ 

P(yl+) 

((fli, . . . ,  6)  G  (x)  ^ 

=  01  X  . . .  X  a„ 

indexed  product 

A' 

yi-H.P5 

P(yl  5) 

{a,b)  e  {X  44  b  C  a;3 

where  dom  a  =  dom  b. 

These  relations  will  be  used  only  when  they  have  well-defined  domains. 

The  following  diagram  shows  commuting  properties  of  relational  constructors: 


3(i?) 


FB 


O) 

B 
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4.8  Compatible  functions. 

Two  functions  axe  said  to  be  compatible  if  their  union  is  also  a  function.  That  is,  their  values  aeree 
whenever  their  domains  overlap.  ° 

The  set  of  pairs  of  compatible  functions  from  4  to  5  is  defined  as  follows; 

Cab  -  dom((u)  >  (j4  -i-^  5)) 

The  functional  forms  of  the  set  operators:  union,  intersection  and  set  difference  are  defined  only  when  the 
arguments  are  compatible  functions.  When  defined,  they  have  the  same  value  as  their  set  equivalents. 


Table  10:  Constructors  on  compatible  functions 


Name 

Symbol 

Definition 

functional  union 

Uab 

Cab  < (U) 

functional  intersection 

Cab  < (n) 

functional  difference 

^AB 

Cab  <  (\) 
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4.9  Diagonal  and  projection 
The  following  axe  defined: 


Table  11:  Diagonal  and  projection  operators 


Name 

Symbol 

Domain 

Range 

Definition 

diagonal 

A„ 

A 

4" 

(fl,  (fll,  •  •  •  ,  fln))  ^ 

^  ai  =  a  A  . . .  A  =  a, 
where  n  >  1 

projection 

TT,- 

e 

X 

X 

X 

X 

G  TTj 

^  a  —  aij  where  1  <  i  <  n 

4.10  Pointwise  product 

The  pointwise  product  i2i  0  ...  0  is  a  relation  from  the  Cartesian  product  of  the  domains  of 
Ri,. ..  ,R„  to  the  Cartesian  product  of  their  ranges. 


Table  12:  Pointwise  product  constructors 


Name 

Form 

Definition 

pointwise  product 

(8)  ...  0  iZn 

((fll,  .  .  .  ,  Uyi))  (^1)  ...»  ^n))  ^  Rl  0  ...  0 

Rn 

^  (oi,  h)  e  Ri  A  ...  A  (a„,  b„)  e  Rn 

iterated  pointwise  product 

i?® 

i?  U  (7?  0  P)  U  (i?  0  i?  0  J?)  u  ... 

The  following  diagram  illustrates  properties  of  the  product  constructors: 


Bi  X  ...  X  Bn 


TTi 


Bi 


i2l  0  ...  ®  Rn 


i4i  X  ...  X  i4„ 


TTi 


A 


Ri 
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4.11  Relational  tuple 

If  A  is  the  intersection  of  the  domains  of  the  relations  iJi, . . . ,  then  the  relational  tuple  (/?i, . . . , 
is  a  relation  from  A  to  the  Cartesian  product  of  their  ranges.  This  is  defined  in  terms  of  the  relational 
product  operator  and  the  diagonal  operator  A„. 


Table  13:  Tuple  constructor 


Name 

Form 

Definition 

relational  tuple 

(Ri,...,R„) 

An  ;  (i?i  0  ...  0  where  n  >  1 

If  the  relations  each  have  domain  A  and  have  range  respectively,  then  the  following 

diagram  shows  the  relationship  between  relational  tuple  (Ri, R„)  and  projection: 


Bi 


Table  14:  Relational  tuple  operator 


Name 

Symbol 

Domain 

Range 

Definition 

relational  tupling 

O 

(A  ^  Si)  X  ^  B2) 

A  < — >  (Rj  X  B2) 

{{Ri,R2),S)  €  0 
<=>  S  =  {Ri,R2) 

Z  Notation  Version  1.1  30th  June  1995 


17 


4  SEMANTIC  METALANGUAGE 


4.12  Promoted  application 

In  order  to  avoid  generating  potentially  undefined  terms,  there  is  no  function  application  in  the  meta¬ 
language  (it  is  used  only  in  explanatory  notes).  For  the  definition  of  function  application  in  Z,  it  is 
necessary  to  define  a  form  of  promoted  application.  For  any  given  a,  the  apply- to- a  function  takes 
as  its  argument  a  function  and  has  as  its  result  the  application  of  that  function  to  the  element  a. 
This  function  can  be  generalised  to  the  promoted  application  operator  {R  •  T),  which  is  the  relational 
analogue  of  the  S  combinator  in  combinatory  logic. 


Table  15:  Promoted  application 


Name 

Form 

Domain 

Range 

Definition 

apply-to-a 

promoted  application 

i-a) 

R*S 

A^B 

A  {B  C)  X  {A  B) 

B 

A<r-^  C 

((3)  n  (a° ;  TTf  ^))  5  712 
{{R  p)  n  (5  ;  TTf^))  5  713 

Note:  If  p  is  a  function  and  c  is  an  member  of  the  domain  of  p  then  the  following  equality 
holds:  (_c)  p  =  p  c.  So  we  have  the  following  equivalence: 

(a,  6)  6  (_c)  (c,  b)  £  a 

If  the  relations  R  :  A  < — >  {B  < — ^  C)  and  S  :  A  ^  B  both  have  the  element  a  in  their  domains, 
then  the  tuple  (o,  (6,  c))  belongs  to  (R  p)  providing  that  (6,  c)  is  a  member  of  the  set  R{a) 
and  it  belongs  to  {S  $  if  b  is  5(0).  The  tuple  (o,  c)  belongs  to  the  whole  relation  exactly 
when  for  some  b  the  tuple  (a,  {b,  c))  belongs  to  the  first  part.  If  R  and  5  are  functions,  then 
promoted  application  is  defined  so  that  the  following  equality  holds: 

{R*S){a)  =  {Ra){Sa) 


Promoted  application  is  disjunctive  in  both  arguments. 

The  apply-to-a  function  (_o)  can  be  derived  from  promoted  application  as  follows: 

(_a)  =  I*a° 

□ 
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5.1  Introduction 


This  section  defines  a  semantic  universe  within  which  the  meanings  of  Z  specifications  lie;  it  is  based 
on  the  Zermelo-Praenkel  axiomatisation  of  sets  mentioned  in  the  last  section. 

The  syntax  of  Z  defines  a  set  of  specifications.  The  semantics  of  Z  defines  a  function  from  these 
specifications  to  meanings  within  the  semantic  universe.  This  universe  contains  the  meanings  of  names 
types,  and  values  used  in  a  specification,  as  well  as  the  environment  used  to  define  the  overall  meaning 
of  a  specification.  It  should  be  noted  that  the  meaning  of  a  specification  is  further  paramatrised  by  the 
assignment  of  sets  to  given  set  names  in  the  specification. 


5.2  Names  and  types 

The  first  task  in  building  the  universe  is  to  explain  the  use  of  names  and  the  notion  of  types.  In  Z  a 
name  used  to  denote  an  element,  which  may  be  a  set,  a  tuple,  a  binding,  or  an  element  of  a  given 
ype.  These  names  come  in  three  varieties:  they  may  be  the  names  of  schemas,  variables,  or  constants. 
This  partitioning  of  abstract  names  is  dependent  on  the  specification  in  question,  the  members  of  each 
set  not  being  distinguishable  in  the  concrete  syntax.  Abstractly,  we  have  that,  for  any  particular  Z 

specification,  our  set  of  names.  Name,  is  comprised  of  schema  names,  variable  names,  and  constant 
names: 

SchemaName  U  Variable  U  Constant  =  Name 

Representation  names  can  have  different  abstract  forms  for  different  specifications;  there  is  assumed  to 
be  an  infinite  supply  of  each. 

In  common  with  other  specification  and  programming  languages,  but  unlike  ZF  set  theory,  the  rules  of 
Z  require  that  every  name  introduced  in  a  Z  specification  is  given  a  particular  type  which  determines 
the  possibilities  for  the  values  that  it  may  take. 

The  simplest  types  are  given  set  names,  which  are  used  to  introduce  abstract  objects  into  a  specification, 

as  the  formal  names  of  generic  parameters  or  as  expressions.  Their  names  are  drawn  from  the  set 
Constant. 

GivenSetName  C  Constant 
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Note:  The  names  Z  for  the  set  of  integers  and  S  for  the  set  of  strings  axe  members  of  the 
set  of  given  set  names.  Le.,  {Z,S}  C  GivenSetName. 

Every  type  belongs  to  the  set  Type,  which  is  pairtitioned  into  the  four  subsets  Gtype,  Ptype^  Ctype, 
and  Stype  representing  the  given  types,  power  set  types,  Cartesian  product  types,  and  schema  types, 
respectively. 

Basic  familiarity  with  elementary  set  theory  leads  one  to  view  something  of  given  type  as  an  object, 
of  power  set  type  as  a  set,  of  Cartesian  product  type  as  a  tuple,  but  what  about  something  of  schema 
type?  It  is  a  partial  function  from  variable  names  to  types;  such  a  function  is  called  a  signature: 

Signature  =  Variable  -h->  Type 

Now  we  have  everything  that  we  need  in  order  to  explain  the  structure  of  the  set  of  types.  Consider  power 
set  types.  Prom  every  type  represented  by  cr,  we  can  construct  the  unique  type  which  is  represented 
by  Per;  every  power  set  type  is  constructed  in  this  way  from  a  unique  type.  Thus,  the  power  set 
type  constructor  is  a  bijection  between  Type  and  Ptype.  Similar  arguments  apply  to  the  other  type 
constructors.  We  can  sum  this  up  by  defining  the  following  four  bijections  with  the  partitions  of  Type: 

givenT  :  GivenSetName  Gtype 
powerT  :  Type  Ptype 
cproductT  :  {Type'^  \  Type)  y^  Gtype 
schemaT  :  Signature  y^  Stype 

Note:  The  signature  parameter  for  the  schemaT  operator  can  be  the  empty  signature. 

For  each  specification  there  is  a  set  of  distinct  given  types.  All  other  types  used  are  constructed  from 
these  given  types  using  a  unique  combination  of  the  type  constructors.  This  uniqueness  is  guaranteed 
because  the  type  constructors  are  in  bijection  with  the  partitions  of  the  set  Type,  Therefore  the  set 
Type  is  the  smallest  set  which  is  closed  under  these  type  constructors.  In  terminology  from  category 
theory.  Type  can  be  described  as  the  initial  algebra  over  the  signature  given  by  givenT,,  powerT^ 
cproductT,  schemaT,  Using  the  notation  for  free  types  as  defined  in  Z,  we  can  sum  this  up  by  defining 
the  set  Type  as  follows: 

Type  ::=  givenT  {{GivenSetName)) 

I  powerT  {{Type)) 

I  cproductT {{{Type"^  \  Type))) 

I  schemaT  {{Signature)) 

5.3  Values  in  Z 

One  of  the  purposes  of  ascribing  a  type  to  a  variable  is  to  determine  which  values  the  variable  may 
take.  To  make  this  possible,  each  type  has  a  (ZF)  set  of  values  associated  with  it,  called  its  carrier  set. 
The  values  in  the  carrier  set  of  a  given  type  are  regarded  as  atomic  objects.  Each  value  in  the  carrier 
set  of  a  non  given  type  is  modelled  by  a  ZF  set.  The  relationship  between  the  types  and  values  in  a 
specification  is  defined  by  the  function  Carrier,  whose  definition  we  approach  inductively  by  defining 
the  carrier  function  for  given  types  and  then  constructing  the  function  for  other  types  from  this. 
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5.3  Values  in  Z 


Note:  In  Z  a  type  is  represented  by  its  carrier  set. 

A  set  jy  will  be  defined  below  to  contain  the  values  of  all  elements  in  Z.  The  carrier  sets  for  each  type 
m  Z  are  subsets  of  W.  The  set  Wo  is  the  set  comprising  the  carrier  sets  for  each  of  the  given  types. 

Definition  5.1  For  each  specification  there  is  a  carrier  function  which  maps  the  given  types  to  elements 
o/Wq. 

Carrier^  :  Gtype  — ^  Wq 


Note:  The  carrier  sets  (elements  of  Wq)  may  be  empty  sets.  This  means  that  the  types  are 
not  inhabited. 


Note:  Suppose  that  7  is  a  given  type;  what  is  the  carrier  set  of  the  power  set  type 

power T  7?  It  IS  simply  the  set  P(  Carrier  7).  In  general,  if  7  is  a  power  set  type  of  a 
given  type  T,  we  must  calculate  the  carrier  set  by  stripping  off  the  power  set  constructor, 
calculating  the  carrier  set  of  this  underlying  given  type,  and  then  forming  the  power  set  of 
the  result.  This  is  given  by  the  expression 

{powerT~^  ;  Carrier^  |  (P))  7 

Similarly,  if  7  is  a  Cartesian  product  of  given  types,  then  we  should  break  it  up  into  its 
constituent  given  types,  determine  their  carrier  sets,  and  then  form  their  Cartesian  product, 
so  that  we  end  up  with  a  set  of  tuple  values: 

{cproductT~'^  ?  Carrier^  ;  (x))7 

Finally,  if  7  is  a  schema  type  constructed  from  given  types,  then  we  should  obtain  the 
underlying  signature;  this  yields  a  function  from  variable  names  to  types,  which  we  must 
turn  into  a  function  from  variable  names  to  the  carrier  sets  of  these  types;  finally,  we  must 
form  the  schema  product,  so  that  we  end  up  with  a  set  of  functions  from  names  to  values: 

{schemaT~^  |  ^{IvaHahie  0  Carrier^)  ;  X)^ 

The  indexed  product  operator  X  is  used  to  convert  a  function  Variable  to  a  set  of 

functions  ^{Variable  -fH  W). 

In  this  discussion,  we  have  assumed  that  the  type  constructors  are  applied  to  given  types,  but  in  general 
they  are  applied  to  arbitrary  types.  Since  a  type  is  made  out  of  a  finite  sequence  of  applications  of  the 
constructors,  we  can  define  the  depth  of  a  type  to  be  the  length  of  this  sequence.  Now  we  can  give  our 
inductive  definition  using  this  notion  of  depth: 
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Definition  5.2 

Carrier  i^i  = 

Carrier  i 

\J  powerT~^  ;  Carrier i  ;  (P) 

U  cproductT~^  5  Carrierf  ;  (x) 

U  schemaT~^  ;  ^{Ivariabie  ^  Carrier i)  9  X 

Note:  The  carrier  set  of  the  schema  type  constructed  from  the  empty  signature  is  the  set 
containing  the  empty  binding. 

In  order  to  calculate  the  carrier  set  for  a  type  7,  we  must  apply  Carrier where  i  is  the  depth  of  type 
7.  Notice  that  every  carrier  function  whose  domain  contains  7  gives  the  same  result  for  7;  this  justifies 
our  general  definition. 

Definition  5.3  The  general  carrier  function  mapping  elements  of  Typeto  their  carrier  sets  is  defined 
as  follows: 

Carrier  =  Carrier^  U  Carrieri  U  Carrier2  U  . . . 

The  values  which  may  be  used  in  a  Z  specification  are  those  that  are  in  the  carrier  sets  that  are  assigned 
to  the  types.  This  set  is  constructed  from  the  elements  of  Wo  using  the  type  constructors. 

Definition  5.4  The  set  W of  all  values  is  the  set  of  all  the  elements  in  each  of  the  carrier  sets  for  the 
elements  of  Type: 

W  =  ^{Carrier  53)  Type 

Definition  5.5  A  binding  is  a  finite  mapping  from  variables  to  values: 

Binding  =  Variable  W 


The  carrier  function  is  a  homomorphism  between  Type  and  W. 


Note:  Thus,  we  have  the  equations  for  carrier 
Carrier  {powerT  7)  =  P  [Carrier  7) 

Carrier  [cproductT  (71, . . . ,  7n))  =  ( Carrier  71)  x  •  •  •  x  ( Carrier  7n) 
Carrier  [schemaT  j)  =  [I  0  Carrier)  7) 


5.4  Elements  in  Z 

Each  element  in  Z  is  represented  by  the  pair  consisting  of  its  type  and  its  value.  The  semantic  set  Elm 
is  a  set  of  type- value  pairs;  this  set  may  be  considered  as  the  relation  between  types  and  values  in  which 
a  type  is  related  to  a  value  if  and  only  if  the  value  is  a  member  of  the  carrier  set  of  the  type. 
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5.4  Elements  in  Z 


Editor’s  note:  The  commuting  diagram  “The  type  system’*  has  been  temporarily  omitted  from  this 
section. 


Definition  5.6  The  set  Elmis  a  set  of  type-value  pairs: 

Elm:F{Typex  W) 

A  value  is  an  element  of  a  type  if  and  only  if  it  is  contained  in  the  carrier  set  of  the  type: 

Elm  =  Carrier  5  3 

Note:  The  set  Elm  of  all  compatible  type-value  pairs  is  also  a  relation  between  types  and 
elements  of  their  carrier  sets.  If  the  carrier  set  for  a  type  is  empty,  then  the  type  will  not 
be  in  the  domain  of  Elm. 

The  first  and  second  projections  on  a  tuple  are  used  to  extract  the  type  and  value  respectively. 

Definition  5.7  The  type  and  value  functions  are  projections  from  the  tuples  in  Elm: 

t  =  Elm  <]  TTi 
v  =  Elm  <  7r2 

Sets  in  Z  are  those  elements  which  have  a  power  type: 

Definition  5.8  The  set  P elm  contains  all  elements  which  have  power  type: 

Pelm  =  Ptype  <  Elm. 

Definition  5.9  The  membership  relation,  3,  for  elements  in  Z  is  a  relation  between  Pelm  and  Elm: 
3  :  Pelm  Elm 

This  relation  is  the  product  of  the  relation  between  a  power  type  and  its  underlying  type  and  the  relation 
between  a  set  and  its  members: 

3  =  {powerT^^  0  3) 

A  Z  specification  consists  of  a  number  of  definitions  which  introduce  names.  Each  name  may  denote 
some  value,  and  each  name  must  have  some  type;  that  is,  each  name  may  be  associated  with  an  element. 
We  dall  such  an  assignment  of  elements  to  names  a  situation. 

Definition  5.10  A  situation  is  a  finite  mapping  from  variables  to  elements: 

Situation  =  Variable  Elm 
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A  situation  tells  us  two  things  about  the  names  in  a  specification;  their  types  and  their  values.  If 
we  think  about  the  type  projection  of  each  name,  then  we  obtain  a  mapping  from  names  to  types:  a 
signature.  If,  on  the  other  hand,  we  think  about  the  value  projection  of  each  name,  then  we  obtain  a 
mapping  from  names  to  values:  a  binding.  The  signature  and  binding  corresponding  to  a  particular 
situation  can  be  extracted  by  the  functions  T  and  V  respectively. 

Definition  5.11  The  Tand  V functions  are  defined  as  follows: 

T  =  ^(^Ivariable  ®  0 
V  =  ^(^Ivariable  ® 

The  following  commuting  diagram,  in  which  fi  is  an  arbitrary  variable  name,  illustrates  the  relationship 
between  types  and  values  and  their  lifted  forms  as  signatures  and  bindings: 


Signature  -> - — - Situation - — - ►  Binding 


(_n) 


Type 


(_n) 


(_n) 


•  Elm 


W 


5.5  Generics 

A  Z  expression  that  involves  a  generic  instantiation  acquires  a  type  and  a  value  that  depends  upon  the 
type  and  value  of  the  expression  used  in  the  instantiation.  Thus  if  we  see  we  know  this  has  a 

different  type  from  The  various  types  that  0  may  take  are  represented  as  a,  function  from  Type 

to  Type.  In  the  case  of  0,  this  function  takes  an  arbitrary  powerset  type  to  itself.  In  general,  where 
a  generic  definition  contains  a  list  of  identifiers,  the  various  possible  instantiations  are  a  function  from 
lists  of  elements  to  a  type  and  value.  The  elements  which  may  appear  as  actual  parameters  of  a  generic 
definition  must  be  of  powerset  type. 


5.5.1  Generic  types 

For  each  generic  type  the  number  of  formal  parameters  is  fixed,  and  every  possible  sequence  of  powerset 
types  with  the  right  number  of  formal  parameters  is  given  a  type.  So  each  generic  type  is  a  function 
from  fixed-length  sequences  of  power  types  to  a  type.  In  order  to  simpUfy  the  definition  of  generic  types 
we  consider  first  the  case  of  the  generic  type  with  n  parameters  and  then  extend  to  the  general  case. 
This  type  is  a  function  from  an  n-tuple  of  power  types  to  a  type.  This  function  must  be  total  as  all 
possible  combinations  of  parameters  must  be  given  a  type. 


24 


Z  Notation  Version  1.1  30th  June  1995 


5.5  Generics 


Definition  5.12  For  any  natural  number  n  >  0,  the  set  of  all  generic  types  with  n  parameters  is 
defined  as  follows: 

Gen-Type n  =  Ptype^  — >  Type 

Since  the  number  of  parameters  for  a  generic  type  is  fixed,  the  general  generic  type  is  an  example  of 
one  of  the  specific  fixed  length  generic  types.  So  the  set  of  all  generic  types  is  the  union  of  all  the  fixed 
length  types. 

Definition  5.13  The  set  of  all  generic  types  is  the  union  of  all  the  sets  of  finite  length  generic  types: 
Gen-Type  =  Gen-Type^  U  Gen-Type2  U  . . . 

Note:  This  models  a  set  far  bigger  than  that  which  can  be  constructed  using  generic  defi¬ 
nitions  in  Z 


5.5.2  Generic  elements 

As  with  generic  types,  for  each  generic  element  there  is  a  fixed  number  of  formal  parameters  that  it 
can  take;  furthermore  every  possible  sequence  of  the  correct  number  of  elements  with  powerset  type  is 
given  a  type  and  value.  Generic  elements  are  defined  in  a  similar  way  to  generic  types:  by  defining  the 
specific  n-length  case  and  generalising. 

For  any  natural  number  n  >  0,  the  set  of  all  generic  elements  with  n  parameters  is  a  subset  of  the  set 
of  functions  from  n-tuples  of  set  elements  to  elements: 

Gen-Elmn  :  F(Pe/m”  — >  Elm) 

The  functions  representing  generic  elements  are  type  consistent;  a  generic  element,  when  instantiated 
with  two  sequences  of  elements  of  the  same  type,  will  give  two  elements  of  the  same  type.  This  is  an 
important  restriction  on  the  functions  used  to  model  generic  elements.  In  order  to  define  this  property 
it  is  necessary  to  characterise  the  type  part  of  a  generic  element. 

Definition  5.14  The  function  takes  a  function  from  n-tuples  of  elements  to  elements  and  returns 
a  relation  from  n-tuples  of  type  to  type: 

Tn  :  {Pelmf"  — ^  Elm)  — >  {Ptype^  ^  Type) 
r„  =  (8)  t) 

The  functions  which  are  to  be  characterised  as  generic  elements  are  those  whose  type  part  is  a  generic 
type,  i.e.  those  whose  type  part  is  functional. 

Definition  5.15  The  set  of  generic  elements  with  n  parameters  are  those  functions  whose  type  part  is 
functionaly  i.e,  contained  in  Gen-Type 

Gen-Elmn  —  dom(rn>  Gen-Type) 
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In  the  same  way  as  for  generic  types,  the  general  generic  element  is  an  example  of  a  specific  one  for 
some  fixed  number  of  parameters. 

Definition  5.16  The  set  of  all  generic  elements  is  the  union  of  all  the  sets  of  finite  length  generic 
elements: 


Gen-Elm  ^  Gen-Elmi  U  Gen-Elm2  U  . . . 


Definition  5.17  The  generic  type  function  can  be  generalised  as  follows: 
r  =  Ti  U  r2  U  . . . 

5.6  Environments 

In  order  to  give  a  meaning  to  the  constructs  of  Z,  we  need  an  environment  to  record  the  elements  denoted 
by  the  names  used  in  a  Z  specification.  The  meaning  of  a  Z  specification  is  a  set  of  environments.  This 
set  contains  those  environments  which  map  the  names  declared  in  the  specification  to  a  combination  of 
values  which  correspond  to  the  constraints  within  the  specification. 

Definition  5.18  An  environment  is  defined  as  a  finite  partial  function  from  names  to  elements  or  ^ 
generic  elements: 

Env  —  Name  -h->  {Elm  U  Gen— Elm) 


Whether  a  Z  specification  is  well  typed  or  not  is  a  question  that  is  independent  of  the  values  of  the 
declared  variables.  To  be  able  to  answer  this  question  it  is  simply  necessary  to  have  an  environment  in 
which  the  types  of  all  names  are  recorded. 


Definition  5.19  A  type-environment  is  defined  as  a  finite  function  from  names  to  types  or  generic 
types: 

Tenv  =  Name  -«->  {Type  U  Gen-Type) 

The  simple  relationship  between  the  richer  environment,  Env,  and  the  one  used  just  for  type  checking, 
Tenv,  is  given  by  the  forgetful  function  T  which  ‘throws  away’  the  values. 

Definition  5.20  The  function  T  maps  the  second  element  of  each  tuple  in  an  environment  onto  its 
corresponding  type  or  generic  type: 

r=^{lName  ®  («  U  t)) 

The  following  commuting  diagram,  in  which  n  is  an  arbitrary  name,  illustrates  the  relationship  between 
the  environment  and  the  type-environment; 
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Tenv 


T 


Env 


(_n) 


(_n) 


Type  U  Gen^Type 


tUr 


Elm  U  Gen^Elm 


Note:  If  T  is  a  set  of  type  environments,  then  ^{T  ^)T  is  the  corresponding  set  of  full 
environments. 


□ 
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6.1  Introduction 

This  section  provides  a  general  introduction  to  the  following  sections  of  the  language  definition,  each 
of  which  defines  a  major  syntactic  category:  expression,  predicate,  schema,  paragraph,  specification. 
Within  each  section  there  are  subsections  corresponding  to  the  syntactic  categories  of  the  abstract 
syntax.  These  follow  a  consistent  pattern,  sub-divided  as  follows;  Abstract  syntax.  Concrete  form. 
Sample  representation  and  transformation.  Type,  and  Value/Meaning. 

A  denotational  style  of  semantic  description  is  used,  as  described  for  example  in  [25]  and,  as  in  the 
customary  style  of  writing  denotational  semantics,  semantic  brackets  are  used  to  delimit  text  for  which 
denotations  are  given.  The  notation  is  extended  by  providing  different  shapes  of  brackets  for  different 
kinds  of  language  elements  as  shown  in  the  following  table.  Three  types  of  semantic  functions  are 
used,  for  type,  value  and  meaning.  The  different  types  are  identified  by,  respectively,  the  superscripts 
T,  V,  M  on  the  brackets. 


Table  16:  Brackets  used  for  semantic  functions 


Bracket 

Argument 

Forms 

i-i 

«-]} 

{-} 

{-) 

?  -  ? 

Expression 

Predicate 

Schema 

Paragraph 

Specification 

i-f,  i-iM-r 
{[_r,  n-F.  i-v 
d-T,  d-r 
d-r,  d-r 

7  7r  ?  9M 
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6.2  Abstract  syntax 

The  following  meta- variables  are  used  for  expressing  the  representation  syntax^  i.e.,  the  visual  form  in 
which  it  appears.  Similar  symbols,  in  bold  font,  are  used  for  expressing  the  abstract  syntax. 


Table  17:  Meta- variables  used  in  the  representation  syntax 


Variables 

Sort 

E,x,y 

Expression 

n,  m 

Name 

a 

String 

i 

Number 

t 

Tuple 

s,  u 

Set- valued  expression 

b 

Binding 

f 

Function 

P,Q 

Predicate 

C,D 

Declaration 

St 

Schema  Text 

S,T 

Schema 

Par 

Paragraph 

6.2  Abstract  syntax 

For  each  language  element,  its  abstract  syntax  is  defined  in  a  form  of  BNF.  The  following  example 
illustrates  the  style  used. 

POWERSET  =  PowEXP 


In  some  cases  symbols  such  as  6  are  used  rather  than  key-words  or  other  structures  in  the  syntax  to 
make  reading  of  the  abstract  syntax  easier.  The  abstract  syntax  is  presented  in  Annex  A. 


6.3  Concrete  form,  representation  and  transformation 


Editor’s  note:  This,  and  the  next  subsections,  have  been  revised  to  account  for  the  new  concrete  syntax 
and  lexis. 

Check  carefully!  JEN 
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For  each  language  element,  there  is  an  example  of  the  concrete  form  showing  a  production  or  productions 
of  the  language  element  being  defined,  together  with  a  table  showing  the  relationship  between  the 
representation  and  abstract  forms. 


Note:  There  may  be  more  than  one  representation  of  an  abstract  syntax  category;  in  such 
cases  all  forms  are  listed.  In  some  cases  the  multiplicity  of  representations  is  due  to  the  fact 
that  some  forms  can  be  considered  as  abbreviations  of  others. 


Transformations  are  presented  in  a  denotational  style.  Superscripts  on  brackets  denote  the  type  of  the 
argument. 


Table  18:  Transformation  functions 


Brackets 

Argument 

[-f 

Expression 

i-f 

Predicate 

i-f 

Declaration 

[-f 

Schema 

1 

1 

Paragraph 

The  following  example  illustrates  how  a  sample  form  from  the  concrete  syntax  is  presented,  together 
with  a  metalanguage  version  of  the  representation  and  its  corresponding  abstract  form: 


Concrete  form 

PSET  Expression 


Sample  representation  and  transformation 


Representation 

Abstract 

Vs 

Powlsf 

In  this  example  the  production  for  power  set  shows  how  a  power  set  is  represented  as  an  expression 
prefixed  with  the  power  set  symbol.  The  first  column  in  the  table  gives  an  example  of  the  representation 
form.  In  this  case  s  is  some  expression  for  a  set  in  representational  form.  The  second  column  gives  the 
abstract  form  of  this  expression.  In  this  case  the  form  is  an  (abstract)  powerset  symbol,  followed  by 
the  abstract  form  of  the  expression  s. 
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These  two  columns  can  be  read  as  an  equation  in  the  form: 


[Fsf  =  Powisf 


The  concrete  syntax  is  presented  in  Annex  B. 


6.4  Type 

The  definition  of  the  Z  type  system  is  by  structural  induction  over  the  abstract  representation  of  a  Z 
specification.  The  well-typedness  of  a  Z  specification  can  be  determined  independently  of  the  values 
of  the  declared  variables.  So  we  see  that  the  following  definition  of  the  Z  type  system  is  entirely 
self-contained:  given  a  Z  specification,  the  type  definitions  determine  whether  that  specification  is 
well-typed. 


Note;  Determining  whether  a  given  specification  is  well-typed  is  a  decidable  question.  Sim¬ 
ilarly,  the  determination  of  the  type  of  any  term,  within  a  given  environment,  is  decidable. 
This  is  in  contrast  with  evaluation  -  determining  whether  a  term  has  a  certain  value  is,  in 
general,  undecidable. 


Table  19:  Type  functions  of  major  forms 


Name 

Form 

Sort 

Expression  Type 

lEf 

Tenv  “H-  Type 

Predicate  Type 

iPV 

P  Tenv 

Schema  Type 

csr 

Tenv  Signature 

Paragraph  Type 

{Par  y 

Tenv  -H-  Tenv 

The  following  example  illustrates  the  description  of  the  type  of  a  powerset: 

Type  The  type  of  the  power  set  Pow  s  is  the  power  set  type  of  the  type  of  the  set  s. 

I  Pow  =  (I  ^  1^  9  powerT 

Note:  A  power  set  Pow  s  is  well  typed  only  if  s  has  power  s6t  type. 

The  type  description  contains  an  informal  description,  the  mathematical  definition  of  the  type  function 
for  the  powerset  and  an  explanation  of  when  it  is  well-typed.  This  last  explanation  is  derived  directly 
from  the  domain  of  the  type  function. 
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Table  20:  Meaning  functions  of  major  forms 


Name 

Form 

Sort 

Expression  Meaning 

lET 

Env  -h>  Elm 

Predicate  Meaning 

{pr 

F  Env 

Schema  Meaning 

Env  Situation 

Paragraph  Meaning 

{Par 

Env  ^  Env 

6.5  Meaning 

The  meanings  of  expression,  predicate,  schema  and  paragraph  are  given  by  the  functions  in  the  following 
table: 


Note:  There  is  a  need  to  explain  that  the  definition  of  Env  is  paramaterised  by  the  assigne- 
ment  of  values  to  the  given  sets. 


The  meanings  of  expression,  predicate,  and  schema  are  combined  to  provide  a  meaning  for  a  paragraph. 
This  meaning  is  a  relation  between  environments.  The  meaning  of  a  specification  is  defined  as  the 
image  of  the  empty  environment  through  the  composition  of  the  relations  for  all  the  paragraphs  in  the 
specification. 

Note:  Now  that  declarations  are  no  longer  in  the  abstract  syntax,  the  example  below  should 
be  replaced. 


The  following  example  illustrates  the  description  of  the  meaning  of  a  simple  declaration: 


Meaning  The  meaning  of  a  compound  declaration  is  the  set  of  situations  that,  when  re¬ 
stricted  to  the  alphabet  of  each  component,  satisfy  that  component: 

Note:  A  compound  declaration  is  value-defined  only  if  both  the  decla¬ 

rations  Di  and  D2  are  value-defined  and  if  repeated  declarations  are  value  com¬ 
patible. 

The  meaning  description  contains  an  informal  description,  the  mathematical  definition  of  the  meaning 
function  for  the  declaration  and  an  explanantion  of  when  it  is  value-defined.  This  last  explanation  is 
derived  directly  from  the  domain  of  the  meaning  function. 

The  meanings  of  pairs  of  expressions,  predicates,  etc.,  can  be  compared.  For  example,  two  expressions 
ei  and  62  are  said  to  be  semantically  equivalent,  written  ei  =  62,  when  =  I  62]*^. 
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6.6  Value 

The  meaning  functions  for  expressions  and  predicates  are  defined  in  terms  of  their  type  and  value.  So 

the  va,lue  functions  axe  the  primitives  defined  in  the  following  sections  and  have  the  structure  shown  in 
the  following  table: 


Table  21:  Value  functions  of  major  forms 


Name 

Form 

Sort 

Expression  Value 

Predicate  Value 

i[pr 

Env  W 

F  Env 

The  following  example  illustrates  the  description  of  the  value  of  a  powerset: 

Value  The  value  of  the  power  set  Pow  s  is  the  set  of  all  the  subsets  of  the  value  of  s: 

I  Pow  sf  =  I  s  5  (P) 

Note:  A  powerset  Pow  s  is  value-defined  only  if  the  expression  s  is  value-defined. 

The  value  description  contains  an  informal  description,  the  mathematical  definition  of  the  value  function 

for  the  powerset  and  an  explanation  of  when  it  is  value-defined.  This  last  explanation  is  derived  directlv 
from  the  domain  of  the  value  function. 

Editor’s  note:  The  following  subsections  need  to  be  revised  and  possibly  moved.  In  Version  1  1  the 
discussion  of  free  variables  has  been  moved  to  Annex  F,  The  logical  theory  of  Z. 


6.7  Free  variables 

Ordinarily  the  definition  of  the  free  variables  of  an  expression  can  be  considered  as  a  function  on  the 
names  of  identifiers  appearing  in  the  text  of  the  expression  and  the  variables  bound  by  the  declarations. 
In  Z  however,  the  case  is  somewhat  more  complicated.  The  use  of  schema  references  as  declarations 
means  that  there  is  an  implicit  declaration.  The  names  introduced  by  the  declaration  S  where  5  is  a 
schema  reference  are  related  not  to  the  name  5  but  to  its  value  in  the  particular  environment  within 
w  ich  it  is  being  evaluated.  In  other  words  the  free  variables  of  an  expression  depend  on  the  text  of  the 
expression  and  the  environment  in  which  the  expression  is  evaluated. 

We  define  the  free  variables  of  an  expression  to  be  a  function  from  environments  to  sets  of  names: 
(j>e{E)  :  Env  P  Name 

The  set  of  names  defined  as  the  free  variables  for  an  expression  for  a  particular  environment  is  the 
smallest  set  of  names  which  must  be  in  the  environment  in  order  for  the  expression  to  be  well-defined. 
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However  since  local  declarations  do  not  introduce  schema  references,  the  free  variables  of  an  expression 
are  unchanged  by  a  local  declaxation.  So  in  the  definitions  we  omit  the  environment  parameter  as  it 
has  no  effect  on  the  value  of  the  free  variables. 

Table  22;  Free  variable  functions 


Function 

Argument 

<l>£ 

Expression 

(jyp 

Predicate 

<t>S 

Schema 
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At  the  end  of  each  section  there  is  a  table  defining  the  free  variables  for  each  construct  within  that 
category.  The  following  example  illustrates  the  definition  of  the  free  variables  of  a  power  set: 

Table  23:  Extract  from  table  of  free  variables 


Expression 

Free  Variables 

Pows 

4>es 

This  can  also  be  read  as  an  equation  in  the  following  form: 

<^fPoW  S  =  <f)£S 
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6.8  Alphabet 

The  syntactic  categories  of  schema  is  used  to  introduce  new  names.  These  new  names  are  called  the 
alphabet  The  alphabet  is  the  set  of  the  names  in  the  signature  as  defined  by  the  type  rules  (where 
applicable). 


Table  24:  Alphabet  function 


Function 

Argument 

a 

Schema 

a 

Schema-text 

a 

Substitution 

Table  25:  Extract  from  table  of  alphabets 


Declaration 

Alphabet 

Til  5  •  •  •  5  5 

{tIi  ,  •  •  .  j  ^T'm} 

This  can  also  be  read  as  an  equation  in  the  following  form: 

^(^15  •  •  •  3  •  •  •  )  ^m} 
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6.9  Substitution 


substituted  expressions  are  given  at  the  end  of  each  section 
These  tables  indicate  when  one  expression  can  be  replaced  by  another  without  changing  the  meaning 
Substitution  IS  defined  using  a  binding,  which  asssigns  values  to  variable  names.  These  new  values  are 
substituted  for  the  variables  in  the  expression. 

The  following  example  illustrates  the  semantic  equivalence  of  substitution  into  a  power  set: 


Table  26.  Extract  from  table  of  semantic  equivalences 


Substitution 

Equivalence 

6oPu 

P(6ow) 

This  can  also  be  read  as  an  equation  in  the  following  form: 

6oPn  ~  P(6otfc), 

where  the  symbol  =  denotes  semantic  equivalence. 

Note:  The  following  is  an  example  of  substitution: 

^  o(r  G  j^riz)  =  SgNHz 

Since  the  variable  name  a  is  not  free  in  the  expression,  there  is  no  substitution  for  it. 

□ 
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Notes  on  this  section  of  the  Z  Steindard 

Section  title:  Expression 

Section  editor:  This  version  edited  by  JEN. 

Note  :  This  version  reflects  comments  by  Jon  Hall,  and  has  been  restruc¬ 
tured  for  the  proposed  concrete  syntax. 

Contributions  by:  Stephen  Brien,  Randolph  Johnson,  . . .  (others  to  be 
added) 

Source  file:  exp.tex 

Most  recent  update:  29th  June  1995 

Formatted:  3rd  July  1995 


7.1  Introduction 

Expression  is  a  general  form  for  defining  values  in  Z. 

In  the  abstract  syntax  given  below,  the  different  kinds  of  Z  expression  are  listed. 


Abstract  Syntax 


EXP  = 


IDENT 

Identifier 

GENINST 

Generic  Instantiation 

NUMBERL 

Number  Literal 

STRINGL 

String  Literal 

SETEXTN 

Set  Extension 

SETCOMP 

Set  Comprehension 

POWERSET 

Power  Set 

TUPLE 

Tuple 

PRODUCT 

Cartesian  Product 

TUPLESELECTION 

Tuple  Selection 

BINDINGEXTN 

Binding  Extension 

THETAEXP 

Theta  Expression 

SCHEMAEXP 

Schema  Expression 

BINDSELECTION 

Binding  Selection 

FUNCTAPP 

Application 

DEFNDESCR 

Definite  Description 

IFTHENELSE 

Conditional  Expression 

EXPSUBSTITUTION 

Substitution 
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7.2  Method  of  definition 


In  this  section,  definitions  are  built  up  in  stages:  first  a  type  function  is  defined, 
From  these,  a  meaning  function  can  be  derived  according  to  rules  given  below. 


then  a  value  function. 


I  J5  :  Tenv  “f->  Type 


The  expression  E  is  well-typed  in  exactly  those  type-environments  contained  in  dom  f  E  V.  The  tvoe  of 
an  expression  m  a  type-environment  is  the  result  of  applying  its  type  function  to  that  type-environinent. 

Value  function.  For  any  expression  E,  its  value  function  (Ef  is  ^  partial  function  from  environ- 
ments  to  values: 

I  :  Env  W 


The  expression  E  is  value-defined  in  exactly  those  environments  contained  in  dom  |[  E  J’'. 

The  value  of  an  expression  in  an  environment  is  the  result  of  the  application  of  its  value  function  to 
that  environment. 


For  some  expressions  the  semantics  is  loosely  defined.  That  is  to  say,  a  lower  bound  on  the  meaning 

IS  given  This  provides  the  possibility  of  various  interpretations,  in  circumstances  where  the  semantics 
does  not  explicitly  give  a  meaning. 


Note:  An  example  is  the  definition  of  Application.  For  example,  in  function  application, 
when  the  argument  is  outside  the  domain  of  the  function,  then  no  meaning  is  explicitly 

given.  Different  interpretations  of  Z  can  ascribe  different  meanings  to  an  ill-formed  function 
application. 


Meaning  function.  The  meaning  function  [  is  a  function  from  environments  to  elements: 
I  -E7 1  :  Env  — Elm 


The  meaning  of  an  expression  in  an  environment  is  the  pair  consisting  of  its  type  and  its  value  in  that 
environment.  The  type  of  an  expression  in  an  environment  is  its  type  evaluated  in  the  corresponding 
type-environment,  which  is  a  restriction  of  the  environment. 

The  function  T  |  |[  £?  corresponds  to  the  type  function  for  E  in  the  full  meaning  environment, 
where  T  is  the  function  that  restricts  an  environment  to  its  corresponding  type-environment  Thus  the 
meaning  function  is  constructed  as  follows: 

I  r  =  (T  I  I  f  ,  [  £  f ) 
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The  expression  E  is  well-defined  in  exactly  those  environments  contained  in  dom  I  which  is  equal 
to: 


domT;f^7]’’  n  dom|£;J’^ 


An  expression  is  said  to  be  well-typed  in  an  environment  if  it  is  well-typed  in  the  corresponding  type 
environment.  Thus,  an  expression  is  well-defined  in  those  environments  in  which  it  is  well-typed  and 
value-defined. 

A  result  of  this  definition  is  that  the  type  of  the  meaning  of  an  expression  in  an  environment  is  always 
the  same  as  the  type  part  of  the  expression  when  evaluated  in  the  corresponding  type-environment: 

c  Tii£;r 


Note:  This  relationship  is  not  an  equality  because  it  is  possible  to  have  well-typed  expres¬ 
sions  which  are  not  value-defined. 


40 


Z  Notation  Version  1.1  30th  June  1995 


7.5  Identifier 


7.3  Identifier 


An  identifier  is  a  name  used  to  refer  to 
on  its  environment. 


a  variable  or  a  constant,  and  it  denotes 


a  value  which 


depends 


Abstract  syntax 

IDENT  =  NAME 


Note:  A  NAME  is  composed  of  a  base-name  suffixed  by  any  number  of  decorations. 
Concrete  form 

X 


Sample  representation  and  transformation 


Representation 

Abstract 

n 

inf 

Type  The  type  of  an  identifier  is  the  type  to  which  the  identifier  is  mapped  in  the  type-environment: 
I  n  1^  =  (_n)  >  Type 

Note:  An  identifier  is  well-typed  if  and  only  if  it  is  in  the  domain  of  the  type-environment. 

mvfionml^:  “  identifier  is  the  value  part  of  the  element  mapped  to  the  identifier  in  the 

=  (_n)|u 


Note:  An  identifier  is  value-defined  in  an  environment  if  and 
the  environment. 


only  if  it  is  in  the  domain  of 


Z  Notation  Version  1.1  30th  June  1995 


41 


7  EXPRESSION 


7.4  Generic  instantiation 

The  generic  instantiation  (m  >  0),  is  the  instantiation  of  the  generic  variable  n  with  the  list 

of  set  expressions  Si, . . . ,  Sm-  The  number  m  must  be  equal  to  the  number  of  formal  parameters  of 
n.  Each  element  of  the  instantiation  list  gives  a  value  to  the  corresponding  generic  parameter  of  the 
generic  variable. 

If  the  list  of  generic  parameters  is  omitted  in  the  representation  form,  it  is  inferred  from  the  typing 
information  in  the  context  of  use;  in  this  case,  the  values  of  the  implicit  parameters  are  the  maximal 
sets  of  the  appropriate  type,  which  must  be  uniquely  determined  by  the  typing  rules. 

Abstract  syntax  A  generic  instantiation  is  constructed  from  a  variable  name  and  a  list  of  one  or 
more  expressions. 

GENINST  =  NAME  [EXP,  EXP, EXP] 


Concrete  form 

NAME  SQBRA  ExpressionListl  SQKET 
Expression! ,  In  Gen ,  Expression 
PreGen ,  Expressions 


Sample  representation  and  transformation  Generic  variables  can  be  instantiated  by  providing  a 
parameter  list,  or  by  infix  or  prefix  means. 


Representation 

Abstract 

”[*!,. ...Sm] 

Sl1pS2 

(j)S 

[[sf ] 

Note:  The  expression  siV’S2,  where  ip  is  an  infix  generic  symbol  is  the  variable  {-ip-)  when 
instantiated  with  the  parameter  list  [si,S2].  When  is  a  prefix  generic  symbol  then  <ps  is 
the  variable  declared  as  {<p-)  when  instantiated  with  the  parameter  list  [s]. 


Type  The  type  of  a  generic  instantiation  is  obtained  by  applying  to  the  types  of  the  actual 

parameters  s,, . . . ,  Sm  the  function  corresponding  to  the  generic  type  of  the  variable  name  n  in  the 
type-environment : 

I  n[5„...,s„)  r  =  (-«)  •  (I  Si  «m  D 

Note:  A  generic  instantiation  is  well-typed  if  and  only  if  the  variable  name  is  in  the  domain 
of  the  type  environment  and  there  is  a  correct  number  of  set-typed  parameters. 
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Value  The  value  of  a  generic  instantiation  n[j,^  is  obtained  by  applying  the  function  corresponding 
to  the  generic  meaning  of  the  variable  name  n  in  the  environment  to  the  meanings  of  the  actual 
parameters  Sj, . . .  and  then  talcing  the  value  part: 

I  r  = 

Note:  A  generic  instantiation  is  value-defined  if  and  only  if  it  is  well-typed  and  all  its 
parameters  are  value-defined. 
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7.5  Number  literal 

A  number  literal  denotes  an  integer. 

Abstract  syntax 

NUMBERL  =  NUMBER 


Concrete  form 
NUMBER 

Sample  representation  and  transformation 


Representation 

Abstract 

i 

bf 

Type  The  type  of  a  number  literal  is  the  given  set  type  of  the  integers. 
I  i  =  Z°  ;  givenT 

Note:  A  number  literal  is  always  well-typed. 

Value  The  value  of  a  number  literal  is  the  integer  it  denotes. 

[if  = 

Note:  A  number  literal  is  always  value-defined. 
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7,6  String  literal 

A  string  literal  denotes  a  string. 


Abstract  syntax 

STRINGL  =  STRING 

Concrete  form 
STRING 

Sample  representation  and  transformation 


Representation 

Abstract 

a 

Type  The  type  of  a  string  literal  is  the  given  set  type  of  the  set  S  of  strings. 
[  a  1^  =  ;  givenT 

Note:  A  string  literal  is  always  well-typed. 

Value  The  value  of  a  string  literal  is  the  string  it  denotes, 
laf  == 

Note:  A  string  literal  is  always  value-defined. 
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7.7  Set  extension 

A  non-empty  set  extension  {x,,..  .,Xm}  is  a  set  containing  exactly  those  elements  denoted  by 

•  •  • )  XjYi  ^  H)* 

Note:  Since  a  set  is  characterised  by  its  members,  the  order  and  duplication  of  elements 
in  Xi, . . . ,  x,„  is  of  no  consequence. 

Abstract  syntax  A  set  extension  is  constructed  from  a  list  of  one  or  more  expressions. 
SETEXTN  =  {EXP,  EXP, . . . ,  EXP} 


Concrete  form 

SETBRA  ExpressionList  SETKET 

‘(’  ,  ExpressionO ,  ,  ExpressionO}  ,  *)’ 

‘I’  , ExpressionO , ExpressionO}  ,  i’ 


Sample  representation  and  transformation  There  are  three  kinds  of  sets  which  can  be  con¬ 
structed  by  extension:  simple  sets,  sequences,  and  bags. 


Representation 

Abstract 

(xi,...  ,Xm} 
(xi,...,Xm} 
|xi,...,Xml 

} 

K{(l,xi),...,(m,x„.)}f 

[{(xi,l)}W...W{(x„.,l)}f 

Note:  The  expression  (xi, . . . ,  x^),  {m  >  0)  defines  an  explicit  construction  of  a  sequence, 
which  can  be  regarded  as  an  ordered  collection  of  its  constituents.  A  sequence  is  modelled  as 
a  partial  function  mapping  the  numbers  1, . . . ,  m  to  the  expressions  xj, . . . ,  respectively. 

Note:  The  expression  [n, . . . ,  {m  >  0)  defines  an  explicit  construction  of  a  bag.  A 
bag  is  a  collection  of  possibly  multiply-occurring  elements.  A  bag  is  modelled  as  a  partial 
function  mapping  its  constituents  to  the  number  of  times  they  occur  within  the  bag. 

Type  The  type  of  a  set  exteasion  {a; . is  the  power  set  type  of  the  common  type  of 

3?!  7  •  •  •  5  ®m* 

I{x„...,x,„}r  =  (Ix,f  n...n[x„,r);pou;err 
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Note:  A  set  extension  {xi, . . . ,  Xm}  is  well  typed  if  and  only  if  all  of  the  expressions 
Xi, . . . ,  Xm  are  well-typed  with  the  same  type. 

Note:  If  a  represents  the  common  type  oi  xi,, . .  ,Xm,  then  Per  represents  the  type  of  the 
set  extension  {3:1, . . . ,  a;yn},  P(Z  x  a)  represents  the  type  of  the  sequence  {xi^.,,,Xm)  and 
P(cr  X  Z)  represents  the  type  of  the  bag  [rci, . . . ,  rcrn]. 


Value  The  value  of  a  set  extension  {xi, . . . ,  Xm}  is  the  set  of  the  values  of  Xj, . . . ,  Xm' 

I  r  =  (I  aJi  r>  I  {••} 

Note;  A  set  extension  {xi, . . . ,  Xm}  is  value-defined  if  and  only  if  all  of  Xi, . . , ,  Xm  are 
value-defined. 

Note:  Two  sets  {a:i, . . . , and  {  J/i,  y2>  •  •  •  >  ym  }  are  equal  if  and  only  if  for  all  i  there 

exists  j  such  that  Xi  =  yjy  1  <  i  <  n 

and  for  all  j  there  exists  k  such  that  yj  =  Xk,  1  <  j  <  m 
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7.8  Set  comprehension 

The  set  comprehension  {St  •  x}  is  the  set  that  contains  exactly  those  elements  denoted  by  the  expres¬ 
sion  X  when  evaluated  in  each  enrichment  of  the  current  environment  by  the  schema  text  St. 

Abstract  syntax  A  set  comprehension  is  constructed  from  a  schema  text  and  an  expression. 

SETCOMP  =  {SCHEMA  •  EXP} 


Concrete  form 

SETBRA  TextOrEbcpression  DOT  Expression  SETKET 
‘{’  ,SchemaText,  “}’ 

‘A’  .SchemaText,  ‘e’  , Expression 

Sample  representation  and  transformation  There  are  two  ways  of  constructing  a  set  by  compre¬ 
hension:  a  simple  set  (for  which  the  expression  part  is  optional)  and  a  lambda  expression. 


Representation 

Abstract 

{St  •  x} 

{St} 

XSt  •  X 

{istf^*uf} 

{lStf'^*l{St)^f} 

Note:  If  the  expression  part  of  the  set  comprehension  is  omitted  then  the  default  is  the 
characteristic  tuple  of  the  schema  text. 

Note:  A  lambda  expression  denotes  a  function.  The  parameter  is  the  characteristic  tuple 
of  the  SchemaText.  The  domain  is  defined  by  the  SchemaText.  The  value  of  the  function  for 
a  given  parameter  is  defined  by  the  value  of  the  Expression  for  the  value  of  that  parameter. 


Editor’s  note:  A  definition  of  x  'S  needed  here. 


Type  The  type  of  a  set  comprehension  {St  •  x}  is  the  power  set  type  of  the  type  of  ®  in  the  type- 
environment  enriched  by  the  declaration  St: 

|{5t*x}r  =  (5t  r  ?  I  ®  r  ?  powerT 

Note:  A  set  comprehension  {St  •  x}  is  well-typed  if  and  only  if  St  is  well-typed,  and  x  is 
well-typed  in  the  type-environment  enriched  by  St. 
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Value  The  value  of  a  set  comprehension  {St  •  ac},  is  the  set  of  the  values  denoted  by  the  expression 
X  in  each  of  the  enrichments  of  the  environment  by  the  schema  text  St: 

Note:  A  set  comprehension  is  always  value-defined. 
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7.9  Power  set 

The  power  set  Ps  is  the  set  of  all  subsets  of  the  set  s. 

Abstract  syntax  A  power  set  is  constructed  from  an  expression. 
POWERSET  =  PowEXP 


Concrete  form 

PSET  Expression 

Sample  representation  and  transformation 


Representation 

Abstract 

Ps 

Pow[sf 

Type  The  type  of  the  power  set  P  s  is  the  power  set  type  of  the  type  of  the  set  s. 

I  Pow  s  1"^  =  (I  s  r  >  Ptype)  9  powerT 

Note:  A  power  set  P  s  is  well-typed  if  and  only  if  s  has  power  set  type. 

Note:  If  P<T  represents  the  type  of  the  set  s,  then  PPff  represents  the  type  of  P s,  a  set  of 
sets. 

Value  The  value  of  the  power  set  P  s  is  the  set  of  all  the  subsets  of  the  value  of  s: 

[  Pow  s  J''  =  I  s  ;  (P) 

Note:  A  power  set  P  s  is  value-defined  if  and  only  if  the  expression  s  is  value-defined. 
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7.10  Tuple 

A  tuple  (aji, . . .  ,cc77i)  (m  >  1)  is  an  ordered  collection  of  the  elements  The  elements 

Xi, . . . ,  Xm  are  not  required  to  have  the  same  type. 

Note:  The  tuples  (a,  6,  c)  and  ((a,  6),  c)  are  distinct:  the  first  contains  three  components 
a,  6,  c  whereas  the  second  has  components  (a,  b)  and  c. 

Note:  The  expression  (a)  is  not  a  tuple;  it  is  the  expression  a  within  parentheses. 


Abstract  syntax  A  tuple  is  constructed  from  a  list  of  two  or  more  expressions. 
TUPLE  =  (EXP,  EXP, . . . ,  EXP) 


Concrete  form 

BRA  Expression  COMMA  ExpressionListl  KET 
Sample  representation  and  transformation 


Representation 

Abstract 

Type  The  type  of  a  tuple  (cCi, . . . ,  is  the  Cartesian  product  type  formed  from  the  types  of 

a?!  ,  •  •  .  ,  Xfjri’ 

|(a;i,...,Xm)  =  {Ix^  f XmV}°,cproductT 

Note:  A  tuple  {x^, . . .  ,Xm){m  >  1)  is  well-typed  if  and  only  if  all  of  Xi,...,Xm  axe 
well-typed. 

Value  The  value  of  a  tuple  {x^,...,  Xm){m  >  1)  is  the  tuple  formed  from  the  values  of  Xj, . . . ,  Xm- 

I  (Xi,...,Xot)  =  (I  ®i  F> 

Note:  A  tuple  (xi, . . . , Xm)  is  value-defined  if  and  only  if  all  of  Xi, Xm  axe  value- 
defined. 
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7.11  Cartesian  product 

The  expression  Si  X  . . .  X  (m  >  1)  is  the  Cartesian  product  of  the  sets  Sj, . . . , 

The  sets  Si,. ..  ,Sm  are  not  required  to  have  the  same  type. 

Note:  As  with  tuples,  the  Cartesian  products  a  x  b  x  c  and  (o  x  6)  x  c  are  distinct. 

Abstract  syntax  A  Cartesian  product  is  constructed  from  two  or  more  expressions. 
PRODUCT  =  EXP  X  EXP  X  ...  X  EXP 


Concrete  form 

Expression  CROSS  Expression  CROSS  Expression 


Sample  representation  and  transformation 


Representation 

Abstract 

5i  X  ...  X  Sfn 

j:sifx...xM^ 

Type  The  type  of  a  Cartesian  product  Si  X  ...  X  s^(m  >  1)  is  the  power  set  type  of  the  Cartesian 
product  type  of  the  list  of  the  underlying  types  of  the  sets  s  15  ...  5  Srn- 

[  Si  X  . . .  X  Sm  =  (I  Si  1'^  ;  powerT-^, . . . ,  I  Sm  F  ?  powerT~'^)  |  cproductT  ?  powerT 

Note:  A  Cartesian  product  Si  X  . . .  X  s^  is  well-typed  if  and  only  if  all  of  the  elements 
(5i5  . . .  5  5m)  have  power  set  types. 


Value  The  value  of  a  Cartesian  product  X  ...  X  Sm{m  >  1)  is  the  Cartesian  product  of  the  values 
of  the  sets  {s  1 5  ...  5  Sm)‘ 

|SiX...XSmF  =  (I  F>  9  X 

Note:  A  Cartesian  product  Si  X  . . .  X  s„  is  value-defined  if  and  only  if  all  of  the  sets 

Si, ...  ,s„  are  value-defined. 

Note:  If  €  Si  for  1  <  i  <  m,  then  the  tuple  (ri, . . . ,  im)  is  an  element  of  si  x  . . .  x  s^- 
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7,12  Tuple  selection 

The  tuple  selection  t.i  is  the  ith  element  in  the  tuple  t. 

Abstract  syntax  A  tuple  selection  is  constructed  from  an  expression  and  a  number  literal. 
TUPLESELECTION  =  EXP  .  NUMBERL 


Note:  The  syntactic  category  NUMBERL  is  used  to  ensure  well-typedness  of  selection. 

Concrete  form 

Expression  SELECT  NUMBER 

Sample  representation  and  transformation 


Representation 

Abstract 

t.i 

Type  The  type  of  a  tuple  selection  t.i  is  the  type  of  the  ith  element  of  the  tuple  t. 

I  t.i  =  1 1 ;  cproductT~^  \  TTj 

Note:  The  tuple  selection  tA  is  well-typed  if  and  only  if  t  has  a  Cartesian  product  type 
with  at  least  i  elements. 


Value  The  value  of  a  tuple  selection  t.i  is  the  value  of  the  zth  element  of  the  tuple  t. 

ItAf  = 

Note:  The  tuple  selection  t.i  is  value-defined  if  and  only  if  t  has  the  value  of  a  tuple  with 
at  least  i  elements. 
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7.13  Binding  extension 

A  binding  extension  ^  Xi, . . .  ^  Tim  >  0)  is  the  binding  that  maps  the  names  tIj,  * .  >  >  Tim 

to  the  values  of  the  expressions  x^,...,Xm  respectively. 

Abstract  syntax  A  binding  extension  is  constructed  from  a  list  of  names  and  expressions. 
BINDINGEXTN  =  ^  NAME  :=  EXP, NAME  ~  EXP^ 


Concrete  form 

BINDERBRA  BindList  BINDERKET 


Sample  representation  and  transforination 


Representation 

Abstract 

L 

\  m  Xl, . .  .  ,  rim 

<1  Kf >  •  •  •  > 

Type  The  type  of  a  binding  extension  ^  nj  Xj, . . . ,  Tim  >  0) 

is  the  schema  type  of  the  signature  constructed  from  the  mapping  of  the  names  ,  Tim  to  the  types 

of  the  expressions  Xi, . . . ,  Xm- 

I  ^  Til  ®i>  •  •  •  j  I  ®i  1^))  •  •  •  >  I  I  ))?{••}?  schcmaT 

Note:  A  binding  extension  {|  Ui  Xj, . . . ,  Um  is  well-typed  if  and  only  if  the 

expressions  Xj, . . . ,  Xm  all  well-typed,  and  the  names  are  distinct. 

Value  The  value  of  a  binding  extension  <|  rii  x,, . . .  ,ti„,  Xm\  (m  >  0)  is  the  binding  con¬ 
structed  from  the  mapping  of  the  names  rii, . . . ,  Um  to  the  values  of  the  expressions  Xi, . . . ,  Xm- 

[  <]  Tlj  Xi,  .  .  .  ,  Tim  =  ((^1>  I  l'^)>  •  ■  •  )  (’^m)  I  1  ))  ?  {•  •} 

Note:  A  binding  extension  ^  rii  Xi, . . . ,  Xm)  is  value-defined  if  and  only  if  the 

expressions  Xi, . . . ,  x,„  are  all  value-defined. 
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7.14  Theta  expression 

The  theta  expression  $  S  is  the  binding  whose  type  is  constructed  from  the  signature  of  S  and  whose 
value  is  the  binding  constructed  from  the  mapping  of  the  names  of  the  signature  to  their  values  in  the 
environment.  The  theta  expression  9  is  the  binding  whose  type  is  constructed  from  the  signature  of 
S  and  whose  value  is  the  binding  constructed  from  the  mapping  of  the  names  of  the  signature  to  the 
values  in  the  environment  of  those  names  when  decorated  by 


Abstract  syntax  A  theta  expression  is  constructed  from  a  schema  and  an  optional  decoration. 
THETAEXP  =  0  SCHEMA  DECOR 


Note:  The  schema  may  itself  be  decorated.  Thus  the  following  are  permitted;  6  S  ^  and 


Note:  Only  non-generic  schemas  may  be  used  in  theta  expressions. 


Concrete  form 

THETA  Expression 


Sample  representation  zind  transformation 


Representation 

Abstract 

e  SI 

9  s 

eisf 

Type  The  type  of  0  5  {6  S^)  is  the  schema  type  constructed  from  the  signature  of  S  whose  com¬ 
ponents  (when  decorated  by  have  the  same  non-generic  type  as  the  corresponding  variable  in  the 
type-environment: 

I  0S  1^  =  (([  S  ])^  n  D)  I  schemaT 
I  059  1"^  =  (([  5  n  (□;  3((  qr  O  1)))  I  schemaT 

Note:  A  theta  expression  is  well-typed  if  and  only  if  each  of  the  decorated  versions  of  the 
names  of  the  signature  of  the  schema  is  assigned  a  non-generic  type  in  the  type-environment 
which  is  the  same  as  the  type  of  that  name  in  the  signature. 
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Note:  The  type  of  a  theta  expression  0  5  «  is  not  the  type  taken  from  S  decorated  by 
The  decoration  ^  does  not  necessarily  appear  in  the  resulting  type.  The  use  of  the  schema 
is  to  identify  the  type  of  the  resulting  binding.  Decoration  is  used  only  to  identify  which 
names  to  look  up  in  the  type-environment;  thus  9 and  6 are  of  the  same  type  even 
if  *■  and  ^  axe  different  decorations. 


Value  The  value  of  the  theta  expression  9S  {6  S^)  is  a  binding  of  the  names  of  the  components  of 
S  to  the  values  of  the  names  (when  decorated  by  «)  in  the  environment: 

I  05  ]''  =  T  ;  ([  5  I  schemaT  ?  Elm  n  D;  V 
I  1'"  =  T  ;  ([  5  I  schemaT  ?  Elm  n  D;  ^((  q)^  0  v) 

Note:  A  well-typed  theta  expression  is  always  value-defined.  The  value  of  the  theta- 
expression  does  not  have  to  satisfy  the  property  of  the  schema. 
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7.15  Schema  expression 

A  schema  expression  S  is  the  set  of  bindings  defined  by  the  schema  S. 

Abstract  syntax  A  schema  expression  is  constructed  from  a  schema. 

SCHEMAEXP  =  SCHEMA 


Concrete  form 

SCHEMA  (NB  add  to  syntax) 

Sample  representation  and  transformation 


Representation 

Abstract 

s 

isf 

Type  The  type  of  a  schema  expression  S  is  the  power  set  type  of  the  schema  type  constructed  from 
the  signature  of  the  schema  S: 

I  5  =  ([  5  ])^  5  schemaT  ;  powerT 

Note:  A  schema  expression  S  is  well-typed  if  and  only  if  the  schema  S  is  well-typed. 


Note:  The  type  of  a  schema  expression  is  not  in  the  range  of  schemaT:  it  is  in  the  range 
of  schemaT  |  powerT.  The  relationship  between  (  and  |  is  that  of  schemaT  ; 
powerT. 


Value  The  value  of  a  schema  expression  S  is  the  set  of  bindings  defined  by  the  schema  S: 
I  5  f  =  ^(([  5  I 

Note:  A  schema  expression  S  is  always  value-defined. 
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7.16  Binding  selection 

The  binding  selection  b.n  is  the  element  to  which  the  name  n  is  mapped  in  the  binding  b. 

Abstract  syntax  A  binding  selection  is  constructed  from  a  binding  and  a  name. 

BINDSELECTION  =  EXP  .  NAME 


Concrete  form 

Expression  SELECT  NAME 


Sample  representation  and  transformation 


Representation 

Abstract 

b.n 

ibf-lnf 

Type  The  type  of  a  binding  selection  b.n  is  the  type  to  which  the  name  n  is  mapped  in  the  signature 
used  to  construct  the  schema  type  of  the  binding  b: 

1  6.  n  1"^  =  1  6  1^  5  schemaT~^  ;  (_ti) 

Note;  A  binding  selection  b.n  is  well-typed  if  and  only  if  the  type  of  6  is  a  schema  type  and 
the  name  n  is  in  the  domain  of  the  signature  from  which  the  schema  type  is  constructed. 


Value  The  value  of  a  binding  selection  b.n  is  the  value  to  which  the  name  n  is  mapped  in  the 
binding  b: 

Ih.nf  =  I6r?(-n) 

Note:  A  binding  selection  b.n  is  value-defined  if  and  only  if  the  binding  b  is  value-defined 
and  the  name  n  is  in  its  domain. 

Note:  Two  bindings  x  and  y  with  components  ni, . . . ,  rim  are  equal  if  and  only  if  a:.n<  = 
y.m,  I  <i  <m. 
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7.17  Application 

The  application  f  x  is  the  result  of  applying  /  to  the  argument  a;. 


Abstract  syntax 

FUNCTAPP  =  EXP  (  EXP  ) 


Sample  representation  and  transformation  There  are  four  ways  of  representing  an  application: 
a  prefix  form,  an  infix  form,  a  superscript  form  and  a  postfix  form.  For  applications  declared  for  use  in 
postfix  or  infix  form,  underscores  indicate  the  positions  of  the  operands.  The  complete  name  includes 
the  underscores  and  surrounding  parentheses  which  are  omitted  when  the  operands  are  supplied  in  the 
form  defined  in  the  declaxation. 


Concrete  form 

Prefix  Expression 

XX 

XXX 

xxxx 


Representation 

Abstract 

fx 

ufuf 

x<j>y 

X^ 

Note:  The  application  x  cj)  y  is  the  infix  application  of  the  relation  (  _  ^  _  )  applied  to  the 
pair  of  arguments  (r,  y). 


Note:  The  application  denotes  the  r-iteration  of  the  relation  i?;  it  is  an  abbreviation 
of  the  expression  iter  x  R, 


Note;  The  application  x<f>  is  the  postfix  application  of  the  relation  (  _  (f>)  applied  to  the 
argument  x. 
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Type  In  the  expression  f  x  the  type  of  f  must  be  the  power  set  type  of  the  Cartesian  product  type 
of  a  pair  of  types,  and  the  type  of  the  argument  x  must  be  the  first  type  in  this  pair;  the  type  of  /  x 
is  the  second  type  in  the  pair. 

I  /  ®  1^  =  (l  /  1^  I  powerT~^  ?  cproductT~^  ;  {-})  •  [  ® 

Note:  The  application  /  x  is  well-typed  only  if  the  type  of  /  is  a  power  set  type  of  a  pair 
of  types  with  the  first  type  in  the  pair  the  same  as  the  type  of  x. 

Note:  If  we  evaluate  the  type  of  f,  we  get  essentially  a  set  of  pairs,  where  each  pair 

comprises  the  type  of  an  argument  and  the  type  of  its  result.  If  we  next  evaluate  the  type 
of  the  particular  argument  x,  then  we  can  simply  use  the  type  of  /  as  a  function  to  look  up 
the  type  of  the  result  corresponding  to  x.  We  say  the  the  type  of  /  is  essentially  a  set  of 
pairs,  because  we  must  ‘undo’  the  type  constructors. 


Value  The  value  of  an  application  f  x  is  given  by  applying  the  value  of  /  to  the  value  of  the  argument 
x: 


Ifxf  2  M/r *1^1") ;{-}-' 

Note:  A  well-typed  application  f  x  is  value-defined  if  both  f  and  x  are  value-defined  and 
if  there  is  a  unique  w  such  that  (x,  m)  G  /. 

Note:  A  relation  is  a  set  of  pairs;  the  first  element  of  each  pair  represents  an  argument, 
and  the  second  the  result  for  that  argument.  For  the  application  /  x  to  be  defined,  /  must 
be  functional  at  x.  Providing  that  x  evaluates  in  the  environment  p  to  a  value  v,  and  the 
value  of  /  in  p  contains  {v,  w),  and  no  other  pair  starting  with  v,  then  the  expression  (/  x) 
evaluates  to  w.  So  for  a  well-defined  function  application  we  would  expect  an  equality  of 
the  following  form: 

The  promoted  application  I/F*!®]''  provides  a  satisfactory  meaning  when  the  applica¬ 
tion  is  value-defined.  It  is  necessary  to  decide  what  to  do  with  f  x  when  f  is  not  functional 
at  X.  This  arises  if  there  are  several  pairs  in  the  value  of  / ,  each  having  the  same  first  ele¬ 
ment  equal  to  the  value  of  x  or  if  there  is  none.  The  definition  provided  does  not  prescribe 
a  value  for  a  relation  applied  outside  its  domain  or  where  it  is  non-functional. 
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7.18  Definite  description 

The  definite  description  ^St  •  x  is  the  element  denoted  by  x  in  the  unique  enrichment  of  the  environ¬ 
ment  by  the  schema  text  St. 

Abstract  syntax  A  definite  description  is  constructed  from  a  schema  text  and  an  expression. 
DEFNDESCR  =  //SCHEMA  •EXP 


Concrete  form 

BRA  MU  TextOrExpression  KET 

Sample  representation  and  transformation  In  the  representation  form  for  definite  description, 
the  expression  part  is  optional. 


Representation 

Abstract 

fiSt  •  X 

pSt 

Note:  If  the  expression  part  of  the  definite  description  is  omitted  then  the  default  is  the 
characteristic  tuple  of  the  schema  text. 


^IVp®  The  type  of  the  term  //  St  •  a;  is  the  type  of  x  in  the  type-environment  enriched  by  St: 

Note:  The  expression  ptStmx  is  well-typed  if  and  only  if  St  is  well-typed,  and  x  is 

well-typed  in  the  type-environment  enriched  by  St. 


Value  The  value  of  a  definite  description  pi  St  •  x  is  the  value  of  x  in  the  unique  enrichment  of  the 
environment  by  St: 

IpSt.xr  2  5  5  I  aj  f 

Note:  A  well-typed  definite  description  St  m  x  is  value-defined  if  there  is  exactly  one 
defined  enrichment  of  the  environment  by  the  schema  text  St  and  the  expression  x  is  value- 
defined  in  that  enriched  environment. 

Note:  This  definition  is  not  specific  about  the  value  of  an  improper  definite  description.  If 
there  is  no  unique  enrichment  of  the  environment  then  the  value  is  not  prescribed;  hence 
the  use  of  D  in  the  definition. 
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7.19  Conditional  expression 

The  conditional  expression  if  P  then  x  else  y  denotes  an  expression  which  is  equal  to  x  if  the 
predicate  P  is  true,  otherwise  it  is  equal  to  the  expression  y. 

Abstract  syntax  A  conditional  expression  is  constructed  from  a  predicate  and  two  expressions. 
IFTHENELSE  =  if  PRED  then  EXP  else  EXP  fi 


Concrete  form 

IF  Predicate  THEN  Expression  ELSE  Expression 
Sample  representation  and  transformation 


Representation 

Abstract 

//  P  Then  x  Else  y 

if[P|^then[a;]^else[j/3^ 

Type  The  type  of  the  conditional  expression  if  P  then  x  else  y  is  the  common  type  of  the  expres¬ 
sions  X  and  y  when  the  predicate  P  is  well-typed; 

I  if  P  then  x  else  y  ^  =  -{[P  <  (I  aj  T  n  [  y 

Note:  The  expression  if  P  then  x  else  y  is  well-typed  if  and  only  if  the  predicate  P  is 
well-typed  and  the  expressions  x  and  y  are  both  well-typed  with  the  same  type. 


Value  The  value  of  the  conditional  expression  if  P  then  x  else  y  is  the  value  of  the  expression  x 
when  the  predicate  P  is  true,  otherwise  it  is  the  value  of  the  expression  y. 

[if  P  then  a:  else  yf  =  ({[P  T  <  I  ®  D  U  (fP  T  ^  [  1/ f ) 

Note:  The  expression  if  P  then  x  else  y  is  value-defined  if  and  only  if  the  predicate  P 
is  true  and  the  expression  x  is  value-defined  or  the  predicate  -iP  is  true  and  the  expression 
y  is  value-defined. 
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7.20  Substitution 

The  expression  box  denotes  an  expression  equal  to  x  in  the  environment  enriched  by  the  binding  b. 


Abstract  syntax  An  expression  substitution  is  constructed  from  a  binding  and  an  expression. 
EXPSUBSTITUTION  =  EXP  o  EXP 


Concrete  form 

Expression  SUBST  Expression 


Sample  representation  and  transformation 


Representation 

Abstract 

box 

Type  The  type  of  the  substitution  box  is  the  type  of  the  expression  x  in  the  type-environment 
enriched  by  the  binding  b. 

I  box  =  (Ij  I  ^  I  schemaT'~^)  ?  0  ?  |  a? 

Note:  The  substitution  box  is  well-typed  if  and  only  if  b  has  schema-type  and  the  expression 
x  is  well-typed  in  the  type-environment  enriched  by  the  binding  6. 


Value  The  value  of  the  substitution  box  is  the  value  of  the  expression  x  in  the  environment  enriched 
by  the  binding  b. 

I  bo®!''  =  (1,1  ?«>>  ?  ®  ?  I  ®  r 

Note:  The  substitution  box  is  value-defined  if  and  only  if  b  is  value-defined  and  the  expres¬ 
sion  X  is  value-defined  in  the  environment  enriched  by  the  binding  b. 
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Editor’s  note;  Revised  versions  of  the  following  subsections  have  been  included  in  Annex  F ,  The  logical 
theory  of  Z. 


Free  variables 
Substitution 
□ 
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Notes  on  this  section  of  the  Z  Standard 

Section  title:  Predicate 

Section  editor:  this  version,  edited  by  JEN 

Original  text  by:  Stephen  Brien 

Contributions  by:  Stephen  Brien,  . . .  (others  to  be  added) 

Source  file:  pred.tex 

Notes:  Updated  for  new  syntax 

Most  recent  update:  29th  June  1995 

Formatted:  3rd  July  1995 


8.1  Introduction 

A  Predicate  is  the  general  form  for  expressing  properties  of  the  environment.  These  properties  are 
relationships  between  the  values  of  the  variables  in  the  environment. 

In  the  abstract  syntax  below  the  different  kinds  of  predicate  are  listed. 

Abstract  syntax 

Equality 
Set  Membership 
Truth  Literal 
False  Literal 
Negation 
Disjunction 
Conjunction 
Implication 
Equivalence 

Universal  Quantification 
Existential  Quantification 
Unique  Existential  Quantification 
Schema  Predicate 
Substitution 


PRED  =  EQUALITY 

1  MEMBERSHIP 
1  TRUTH 
I  FALSEHOOD 
I  NEGATION 
I  DISJUNCTION 
I  CONJUNCTION 
I  IMPLICATION 
I  EQUIVALENCE 
I  UNIVERSALQUANT 
I  EXISTSQUANT 
I  UNIQUEQUANT 
I  SPRED 

I  PREDSUBSTITUTION 


Strategy  for  definition 

The  description  of  the  meaning  of  a  predicate  is  split  into  two  parts.  The  first  part  gives  rules  for 
determining  whether  it  is  well-typed  or  not.  The  second  determines  whether  the  predicate  is  ZF-true 
in  the  environment. 

A  predicate  is  ZF-true  in  an  environment  if  the  values  of  the  sub-expressions  in  the  predicate  are  such 
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that  the  predicate  is  true  in  that  environment,  without  necessarily  considering  whether  the  predicate  is 
well-typed. 

8.1.1  Type 

Since  in  the  abstract  syntax  we  already  know  that  a  certain  construct  is  a  predicate,  when  considering 
the  type  of  a  predicate  the  only  matter  of  concern  is  whether  it  is  well-typed.  For  this  reason  we 
represent  the  type  function  of  a  predicate  as  the  set  of  type-environments  in  which  it  is  well-typed. 

{PRED]}'^  :  FTenv 

Note:  The  predicate  a:  =  y  is  meaningless  if  the  expressions  x  and  y  are  not  of  the  same 
type.  There  is  no  meaningful  way  of  comparing  them. 

Note:  A  predicate  that  is  not  well-typed  in  any  environment  has  a  type  function  that 

evaluates  to  the  empty  set. 


8.1.2  Value 

The  value  function  maps  a  predicate  to  the  set  of  environments  in  which  it  is  ZF-true; 
{[PREDJ'^  :  fEnv 


Note-  The  predicate  -^{x  €  x)  is  ZF-true  in  all  environments.  This  is  so  because,  within  the 
semantic  universe,  the  axiom  of  regularity  ensures  that  x  e  x  is  false  and  hence  -(a:  €  x) 
is  true.  On  the  other  hand,  in  Z,  the  type-system  ensures  that  i  i  is  not  weU-typed  so 
therefore  -‘{x  €  x)  is  not  well-typed. 


8.1.3  Meaning 

The  environments  in  which  a  predicate  is  true  are  exactly  those  environments  in  which  the  predicate  is 
well-typed  and  is  ZF-true. 

{[PRED  :  PFnu 

{[PRED  ==  3(T-1){[PRED  ]}^  n  {[PRED  ^ 

Note-  As  indicated  in  the  note  above,  the  predicate  -.(a:  €  a:)  is  ZF-true  but  not  well-typed, 
hence  it  is  not  true  in  any  environment.  The  meaning  of  the  predicate  is  the  empty  set; 

{xex}^  =0. 
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8.2  Equality 

Two  expressions  axe  equal  if  and  only  if  they  have  the  same  value  and  type. 

Abstract  syntax  An  equality  is  constructed  from  two  expressions. 
EQUALITY  =  EXP  =  EXP 


Concrete  form 

Expression  EQUALS  Expression 

Note:  This  form  is  derived  from  Relation  and  Inf  ixRel 


Sample  representation  and  transformation 


Representation 

Abstract 

=  yf 

Type  An  equality  £C  =  y  is  well-typed  in  those  environments  in  which  the  expressions  x  and  y  have 
the  same  type. 

{x  =  y}'^  =  dom(I  a;  I’’  fl  |  y  1'^) 

Value  An  equality  x  =  y  is  ZF-true  in  those  environments  in  which  the  expressions  x  and  y  have  the 
same  values. 

{x  =  y  ]}^  =  dom(|  x  D  |  y  D 
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8.3  Membership 

The  predicate  x  €  y  is  true  if  and  only  if  the  expression  x  is  a  member  of  the  set  denoted  by  the 
expression  y. 


Abstract  syntax  A  membership  predicate  is  constructed  from  two  expressions. 
MEMBERSHIP  =  EXP  €  EXP 


Concrete  form 

Expression  MEMBER  Expression 

Note:  This  form  is  derived  from  Relation  and  Inf  ixRel 


Sample  representation  and  transformation  There  are  three  ways  in  which  the  membership  pred¬ 
icate  can  be  written:  using  the  membership  sign,  using  an  infix  relation  and  using  a  prefix  relation. 


Representation 

Abstract 

X  ey 

bf 

xpy 

p  X 

I*f  €  Kp  -  )f 

Note:  The  infix  relation  predicate  xpy  is  true  if  the  expression  x  is  related  to  the  expression 
y  by  the  relation  (_p_),  i.e.  if  the  tuple  {x,  y)  is  a  member  of  the  relation  (_p_)- 

Note:  The  prefix  relation  predicate  px  is  true  if  (p-)  is  true  for  x,  i.e.  if  a:  is  a  member  of 
the  set  (/9-). 


Type  A  predicate  x  €  y  is  well-typed  if  and  only  if  the  type  of  the  expression  y  is  the  power  set  type 
of  that  of  the  expression  x. 

{a;  €  y  =  dom(I  x  1'^  ?  powerT  n  [  y  1^) 

Value  A  predicate  x  G  y  is  ZF-true  in  exactly  those  environments  in  which  the  value  of  the  expression 
a;  is  d.  member  of  the  value  of  the  expression  y. 

{x  G  y  r  =  ®  r  1^5''  59) 
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8.4  Truth  literal 

The  truth  literal  true  represents  the  predicate  that  is  always  true. 

Abstract  syntax 

TRUTH  =  true 


Concrete  form 
TRUE 

Sample  representation  and  transformation 


Representation 

Abstract 

true 

true 

Type  The  truth  literal  true  is  well-typed  in  all  type-environments, 
■{[true  ]}^  =  Tenv 

Value  The  truth  literal  true  is  ZF-true  in  all  environments. 

{[true  =  Env 
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8.5  False  literal 

The  false  literal  false  represents  the  predicate  that  is  never  true. 


Abstract  syntax 

FALSEHOOD  =  false 


Concrete  form 
FALSE 

Sample  representation  and  transformation 


Representation 

Abstract 

false 

false 

Type  The  false  literal  false  is  well-typed  in  all  type-environments. 
Ifalse}'^  =  Tenv 

Value  The  false  literal  false  is  not  ZF-true  in  any  environment. 
IfalseY  =  0 
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8.6  Negation 

The  negation  -iP  is  true  if  and  only  if  the  predicate  P  is  not. 

Abstract  syntax  A  negation  is  constructed  from  a  predicate. 
NEGATION  =  -nPRED 

Concrete  form 

NOT  Predicate 

Sample  representation  and  transformation 


Representation 

Abstract 

-.p 

Type  The  negation  -iP  is  well-typed  exactly  when  the  predicate  P  is  well-typed. 

t-pV  =  iPV 

Value  The  negation  -iP  is  ZF-true  in  those  environments  in  which  the  predicate  P  is  not  ZF-true. 

p  r  =  Env  \  iP  r 
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8.7  Disjunction 

The  disjunction  P  V  Q  is  true  if  and  only  if  at  least  one  of  the  predicates  P  and  Q  is  true. 

Abstract  syntax  A  disjunction  is  constructed  from  two  predicates. 

DISJUNCTION  =  PRED  V  PRED 


Concrete  form 

Predicate  DISJ  Predicate 


Editor’s  note:  This  production  seems  to  have  been  omitted  in  the  Concrete  Syntax  document.  JEN 


Sample  representation  and  transformation 


Representation 

Abstract 

pyQ 

IPfylQf 

Type  The  disjunction  P  V  Q  is  well-typed  in  exactly  those  type-environments  in  which  both  predi¬ 
cates  P  and  Q  are  well-typed. 

{PvqV  =  j[P  r  n  iQ  V 

Value  The  disjunction  P  V  Q  is  ZF-true  in  exactly  those  environments  in  which  one  or  both  of  the 
predicates  P  ,  Q  are  ZF-true. 

{pyQr  =  iPV^iQV 
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8.8  Conjunction 

The  conjunction  P  A  Q  is  true  if  both  the  predicates  P  and  Q  are  true. 

Abstract  syntax  A  conjunction  is  constructed  from  two  predicates. 

CONJUNCTION  =  PRED  A  PRED 

Concrete  form 

Predicate  CONJ  Predicate 

Sample  representation  and  transformation  There  are  three  ways  of  constructing  a  conjunction: 
by  a  simple  conjunction,  by  a  compound  relation,  and  by  separating  two  or  more  predicates. 


Representation 

Abstract 

PAQ 

X1  Pi  X2  P2  ...  Pn-l  Xn 

PiSep . . . SepPn 

Pi  X2f’ AIx2  P2  ...Pn-1  Xnf^ 

lPlfA...AlPr.f 

Note:  In  predicates  Sep  is  a  conjunction;  such  a  conjunction  has  the  lowest  possible 

precedence  and  is  equivalent  to  parenthesising  the  separate  predicates  and  conjoining  them. 

Note:  Generic  emtyset  problem. 

Editor’s  note:  Review  this  section! 

Type  The  conjunction  P  A  Q  is  well- typed  in  exactly  those  type-environments  in  which  both  the 
predicates  P  and  Q  are  well-typed. 

{paqv  =  {pr  n  {[Qr 

Value  The  conjunction  of  two  predicates  P  A  Q  is  ZF-true  in  exactly  those  environments  in  which 
both  the  predicates  P  and  Q  are  ZF-true. 

|P  A  Q  J''  =  flp  r  n  iQ  V 
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8.9  Implication 

The  implication  P  Q  is  true  if  and  only  if  the  predicate  P  is  false  or  the  predicate  Q  is  true. 

Abstract  syntax  An  implication  is  constructed  from  two  predicates. 

IMPLICATION  =  PRED  =>  PRED 


Concrete  form 

Predicate  IMPLIES  Predicate 


Sample  representation  and  transformation 


Representation 

Abstract 

P^Q 

lPf=^iQf 

Type  The  implication  P  Q  is  well-typed  in  exactly  those  type-environments  in  which  both  the 
predicates  P  and  Q  are  well-typed. 

IIP  =  HP  ]}^  n  IQ  r 

Value  The  implication  P  Q  is  true  in  exactly  those  environments  in  which  the  predicate  P  is  not 
ZF-true  or  the  predicate  Q  is  ZF-true. 

4P  Q  J''  =  {Env  \  iP  F)  U  iQ  ]}'' 
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8.10  Equivalence 

An  equivalence  P  Q  is  true  if  and  only  if  both  predicates  P  and  Q  are  true  or  neither  is  true. 

Abstract  syntax  An  equivalence  is  constructed  from  two  predicates. 

EQUIVALENCE  =  PRED  o  .  PRED 


Concrete  form 

Predicate  IFF  Predicate 


Sample  representation  and  transformation 


Representation 

Abstract 

P^Q 

Type  The  equivalence  P  ^  Q  is  well- typed  in  exactly  those  type-environments  in  which  both  the 
predicates  P  and  Q  are  well-typed. 

{[p  ^  Q  =  fp  r  n  iQ  V 


Value  The  equivalence  P  Q  is  ZF-true  in  exactly  those  environments  in  which  the  predicates  P 
and  Q  are  both  ZF-true  or  neither  are  ZF-true. 

fp^^-QF  =  {PF  ®  !QF 
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8.11  Universal  quantification 

The  universally  quantified  predicate  V  •  P  is  true  if  the  predicate  P  is  true  for  all  possible  combi¬ 
nations  of  values  of  the  components  of  the  schema  text  St. 

Abstract  syntax  A  universal  quantification  is  constructed  from  a  schema  text  and  a  predicate. 

UNIVERSALQUANT  =  VSCHEMA»PRED 


Concrete  form 

FORALL  TextOrExpression  DOT  Predicate 


Sample  representation  and  transformation 


Representation 

Abstract 

.  P 

Type  A  universal  quantification  V  St  •  P  is  well-typed  in  a  type-environment  if  and  only  if  the 
predicate  P  is  well- typed  in  that  type-environment  enriched  by  the  schema  text  St. 

fV  54  •  P  ]}^  =  dom((5t  >  j[P  ]j-^) 


Meaning  A  universal  quantification  V  5f  •  P  is  ZF-true  in  an  environment  if  and  only  if  the  predicate 
P  is  ZF-true  in  all  enrichments  of  that  environment  by  the  schema  text  St. 

i^sfpy  =  ^{{st}^)ipy 

Note:  This  semantic  definition  rests  on  the  properties  of  de  Morgan’s  Laws. 
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8.12  Existential  quantification 

The  existentially  quantified  predicate  3  St*  Pis  true  if  the  predicate  P  is  true  for  at  least  one  possible 
combination  of  values  of  the  components  of  the  schema  text  St. 


Abstract  syntax  An  existential  quantification  is  constructed  firom  a  schema  text  and  a  predicate. 
EXISTSQUANT  =  3  SCHEMA  aPRED 


Concrete  form 

EXISTS  TextOrExpression  DOT  Predicate 


Sample  representation  and  tremsformation 


Representation 

Abstract 

LU 

• 

Type  An  existential  quantification  3  St  •  P  is  well-typed  in  a  type-environment  if  and  only  if  the 
predicate  P  is  well-typed  in  that  type-environment  enriched  by  the  schema  text  St. 

{[3  54  •  P  =  dom((5t  >  -([P  ]}’’”) 


Value  An  existential  quantification  3  St*  Pis  ZF-true  in  an  environment  if  and  only  if  the  predicate 
P  is  ZF-true  in  at  least  one  enrichment  of  that  environment  by  the  schema  text  St. 

i3St*Py  =  domi{St}^{>{Py) 
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8.13  Unique  existential  quantification 

The  unique  existentially  quantified  predicate  3^  St  •  P  is  true  if  the  predicate  P  is  true  for  exactly  one 
possible  combination  of  values  of  the  components  of  the  schema  text  St. 


Abstract  syntEix  A  unique  existential  quantification  is  constructed  from  a  schema  text  and  a  predi¬ 
cate. 

UNIQUEQUANT  =  3,  SCHEMA  •  PRED 


Concrete  form 

EXISTS!  TextOrExpression  DOT  Predicate 


Sample  representation  and  transformation 


Representation 

Abstract 

3^St»P 

Type  A  unique  existential  quantification  3^  St  •  P  is  well- typed  in  a  type-environment  if  and  only 
if  the  predicate  P  is  well-typed  in  that  type-environment  enriched  by  the  schema  text  St. 

{3^  St  •  P  =  dom((St  >  {P  ]}^) 


Value  A  unique  existential  quantification  3^  St  •  P  is  ZF-true  in  an  environment  if  and  only  if  the 
predicate  P  is  ZF-true  in  exactly  one  enrichment  of  that  environment  by  the  schema  text  St. 

=  dom(^((5tr  >{pr)i{-r') 
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8.14  Schema  predicate 

A  schema  predicate  S  is  true  if  and  only  if  the  values  of  the  components  of  the  schema  S  are  contained 
in  the  environment  and  their  values  satisfy  the  property  of  the  schema. 


Abstract  synteix  A  schema  predicate  is  constructed  from  a  schema. 
SPRED  =  SCHEMA 


Concrete  form 

??  —  to  be  defined 


Sample  representation  and  transformation 


Representation 

Abstract 

s 

Type  A  schema  predicate  5  is  well-typed  in  a  type-environment  if  and  only  if  the  schema  S  is  well- 
typed  and  the  signature  of  S  is  contained  in  the  environment. 

{5  =  dom(([  5  n  D) 

Value  A  schema  predicate  S  is  ZF-true  in  an  environment  if  and  only  if  the  environment  contains  a 
situation  of  the  schema  S. 

V  =  dom(([  5  r  n  2) 
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8.15  Substitution 

The  predicate  boP  is  true  if  and  only  if  the  predicate  P  is  true  in  the  environment  enriched  by  the 
binding  6. 


Abstract  syntax  A  substitution  instance  is  constructed  from  an  expression  and  a  predicate. 
PREDSUBSTITUTION  =  EXPgPRED 


Concrete  form 

Expression  SUBST  Predicate 


Sample  representation  and  transformation 


Representation 

Abstract 

beP 

ibf4Pf 

Type  A  predicate  boP  is  well-typed  in  an  type-environment  if  and  only  if  b  is  well-typed  with  a 
schema  type  and  the  predicate  P  is  well  typed  in.  the  environment  enriched  by  the  binding. 

{beP  =  dom((l,  I  b  ?  schemaT'^^)  5  (0)  t>  {[P 

Value  The  predicate  boP  is  ZF-true  in  exactly  those  environments  in  which  the  binding  6  is  value- 
defined  and,  when  enriched  by  b  make  the  predicate  P  ZF-true. 

ibopy  =  dom((l,[6r?0>|(©)D>{Pr) 
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Editor’s  note:  Revised  versions  of  the  following  subsections  have  been  included  in  Annex  F  The  loaical 
theory  of  Z.  >  v 


Free  variables 
Substitution 
□ 
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Notes  on  this  section  of  the  Z  Standard 

Section  title:  Schema 
Source  file:  sch.tex 

Section  editor:  this  version  edited  by  John  Nicholls  (pro  tern) 

Original  text  by:  Stephen  Brien 

Contributions  by:  Stephen  Brien,  be  added) 

Most  recent  update:  29th  June  1995 
Formatted:  3rd  July  1995 


9.1  Introduction 


Editor’s  note:  The  following  note  is  taken  from  the  proposal  by  Rob  Arthan  (dated  27th  June  1992)  to 
allow  schemas  to  be  regarded  as  expressions. 


A  schema  is  an  expression  whose  value  is  a  set  of  bindings. 

A  schema  can  be  used  in  the  following  ways: 

as  a  declaration 
as  a  predicate 

as  an  operand  of  certain  operators  which  construct  schemas  from  other  schemas. 
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Abstract  syntax 

SCHEMA  =  SDECL 

I  SCONSTRUCTION 
I  SNEGATION 
I  SDISJUNCTION 
I  SCONJUNCTION 
I  SIMPLICATION 
I  SEQUIVALENCE 
I  SPROJECTION 
1  SHIDING 
1  SUNIVQUANT 
I  SEXISTSQUANT 
I  SUNIQUEQUANT 
I  SRENAMING 
I  SCOMPOSITION 
I  SDECORATION 
I  SSUBSTITUTION 
I  EXPSCHEMA 


Strategy  for  definition 

When  mahing  schemas,  the  problem  is  not  so  much  whether  it  is  well  defined  (although  a  schema  may 
fail  to  be  defined).  The  problem  is  more  to  record  the  possible  meanings  of  the  declared  names.  The 
definition  is  built  up  in  two  stages.  The  type  function  defines  the  signature  of  a  schema.  The  meaning 
relation  relates  the  environment  to  those  possible  situations  defined  by  the  schema. 

A  schema  can  be  also  used  to  introduce  new  variables  to  the  environment,  A  type  and  meaning  enrich¬ 
ment  function  is  given  for  this  purpose. 


9.1.1  Type  function 

For  any  schema  S  its  type  function  is  a  recursively  defined  partial  function  from  type-environments  to 
signatures  which  record  the  types  of  the  elements  denoted  by  the  variables  introduced: 

{  S  :  Tenv  Signature 

The  schema  S  is  well-typed  in  exactly  those  type-environments  contained  in  dom  {  S  ])^.  The  signature 
of  a  schema  in  a  type-environment  is  the  result  of  applying  its  type  function  to  that  type-environment. 

For  any  schema  S  its  type  enrichment  function  is  a  partial  function  from  a  type-environment  to  a  new 
one  in  which  the  names  of  the  constituent  schema  are  known: 

(5  :  Tenv  Tenv 

{sy  =  (i.dsr)?® 
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9.1.2  Meaning  relation 

A  schema  introduces  names  to  the  environment  which  can  assume  certain  values.  These  values  axe  not 
fixed.  We  can  consider  the  meaning  of  a  schema  as  a  set  of  situations,  each  one  recording  one  set  of 
values  for  the  new  names.  However,  it  is  more  convenient  to  consider  the  meaning  of  a  schema  as  a 
relation  between  environments  and  situations.  For  any  schema  S,  its  meaning  relation  is  a  relation 
firom  environments  to  situations: 

(  S  :  Env  >  Situation 


The  meaning  of  a  schema  in  an  environment  is  any  one  of  the  situations  related  to  that  environment 
by  the  meaning  function.  The  meaning  of  a  schema  is  partial  because  some  schemas  may  fail  -  for 
example  n  :  s  where  s  is  undefined,  or  if  s  is  an  empty  set.  A  schema  S  is  well-defined  in  exactly  those 
environments  contained  in  dom  (  S  ])'^ . 

The  meaning  enrichment  is  represented  as  a  relation  between  environments,  for  the  same  reason  as  the 
meaning  of  a  schema  as  represented  by  a  relation. 

(sr  :  Env  Env 


{S  =  (1,  d  5  D^)  I  © 
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9.2  Schema  designator 

A  schema  designator  is  a  schema  name  used  to  refer  to  schema.  It  may  also  contain  a  list  of  generic 
paramaters  which  instantiate  a  generically  defined  schema. 

Note:  Since  schema  names  have  global  scope  there  cannot  be  any  overlap  between  the  base 
names  of  variables  and  schema  names  in  a  specification. 


Abstract  syntax  A  schema  designator  is  constructed  from  a  schema  name. 
SDES  =  WORD 


Concrete  form 
Nofix 


Sample  representation  and  transformation 


Representation 

Abstract 

s 

s 

Type  The  signature  of  a  schema  reference  is  the  signature  of  the  type  of  the  reference  in  the  type- 
environment. 

([  S  ])^  =  (1  •  5°)  ;  powerT~^  5  schemaT~^ 

Note:  A  schema  reference  is  well-typed  only  if  it  is  in  the  domain  of  the  type-environment. 


Meaning  The  meaning  of  a  schema  reference  is  the  relation  constructed  from  the  meaning  of  the 
reference  in  the  environment. 

Note:  A  schema  reference  is  well-defined  only  if  it  is  in  the  domain  of  the  environment. 
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9.3  Generic  schema  designator 

A  generic  schema  designator  5  [aui, . . . ,  ®n]  is  reference  to  a  generically  defined  schema  S  instantiated 
by  the  set  paramaters  [a^i, . . . ,  a;„]. 


Abstract  syntax  A  generic  schema  designator  is  constructed  from  a  schema  name  and  a  list  of 
expressions. 

SGENDES  =  WORD  [EXP, . . . ,  EXP] 


Concrete  form 

NAME  SQBRA  ExpressionListl  SQKET 
Sample  representation  and  transformation 


Representation 

Abstract 

Type 

([S[x„...,x„]  ])^  =  {{!•  S°)»  {xi,...,Xn))°,powerT-'^  °,schemaT-'^ 
Meaning 

([  S[Xi,  .  .  .  ,  Xn]  j)'^  =  iO-  *  S°)  •  {Xi,. .  .  ,Xn)) 

Note:  Generically  defined  schemas  must  be  instantiated. 
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9.4  Simple  schema 

A  simple  schema  rii, . . .  rim  •  s  introduces  variables  named  rii, . . .  rim  whose  values  are  drawn  from 
the  set  s. 

Abstract  syntax  A  simple  schema  is  constructed  from  a  list  of  names  and  an  expression. 

SDECL  =  NAME,  NAME,...,  NAME  :  EXP 


Concrete  form 

NameListl  COLON  Expression 


Seimple  representation  and  transformation 


Representation 

Abstract 

?^1  >  ^2 )  •  •  •  7  5 

*^15  ^2?  •  •  •  ) 

Type  The  type  of  the  simple  schema  ni,...nyn  :  s  is  the  signature  constructed  from  the  names 
rii, . . .  rim  and  the  underlying  type  of  the  set  expression  s. 

{  s  f  \  {{ni°,powerT~^), . . .  ,{n°^,powerT-^)) ’,  {. . .} 

Note:  The  simple  schema  rii, . . .  rim  •  s  is  well- typed  if  and  only  if  the  expression  s  has 
power  set  type. 


Meaning  The  meaning  of  the  simple  schema  rii, . . .  rim  :  s  is  a  relation  from  the  environment  to  those 
situations  which  associate  each  of  the  names  ni, . . .  rim  with  one  of  the  elements  of  the  set  expression 
s: 


:  s  =  f  s  |  {(ni°,3), . . . ,  (n,„°,3))  ?  {. . .} 

Note:  The  simple  schema  rii, . . .  rim  •  ^  is  well-defined  if  and  only  if  the  expression  s  is  a 
non-empty  set. 

Note:  Suppose  G  is  defined  to  be  a  given  set.  The  type  system  defines  the  type  of  G 
to  be  powerT{givenTN).  In  this  way  a  schema  such  as  x  :  G  defines  the  type  of  x  to  be 
givenT{G),  as  required. 
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9.5  Schema  construction 

A  schema  construction  5  |  P  is  a  schema  whose  signature  is  that  of  the  schema  S  and  whose  components 
satisfy  the  constraint  of  the  schema  S  and  the  predicate  P. 

Abstract  syntjix  A  schema  construction  is  composed  from  a  schema  and  a  predicate. 
SCONSTRUCTION  =  SCHEMA  |  PRED 


Concrete  form 

DeclPart  [VBAR  Predicate] 
SQBRA  Text  SQKET 


Sample  representation  and  transformation 


Representation 

Abstract 

D  1  P 
[D\P] 

[D] 

IDfllPf 

ilDfllPf) 

{{Df  \true) 

Type  The  signature  of  {D  |  P)  is  the  same  as  that  of  the  schema  D. 

{S\P)V  =  f5rn((JD|Pr;D) 


Meaning  The  value  of  the  schema  expression  constructed  from  {D  |  P)  is  a  set  of  bindings.  The 
bindings  are  constructed  in  all  enrichments  of  the  environment  by  D  which  satisfy  P: 

([<r>ip)r  =  c-Drn(piprQ) 

This  is  defined  only  in  those  environments  in  which  the  schema  D  is  defined  and  when  enriched  by  it 
result  in  the  predicate  P  being  well-typed. 
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9.6  Schema  negation 

A  schema  negation  -iS  is  a  schema  which  contains  all  the  bindings  of  the  same  signature  as  those  of 
the  schema  S  but  which  are  not  contained  in  S, 


Abstract  syntax  A  schema  negation  is  composed  of  a  schema 
SNEGATION  =  -i  SCHEMA 


Concrete  form 

NOT  Expression 


Sample  representation  and  transformation 


Representation 

Abstract 

-^S 

-^isf 

Type  The  signature  of  a  negated  schema  “iS  is  the  same  signature  as  that  of  the  schema  S: 


Meaning  The  bindings  of  a  negated  schema  “iiS  are  those  bindings  which  have  the  same  signature  as 
S  but  axe  not  bindings  of  S: 

=  ([ s {^^  \  ([ s 

Note:  This  is  simpler  than  in  (Spivey,  1988),  where  this  complement  had  to  be  combined 
with  the  global  part  of  the  environment.  This  was  necessary  in  the  original  semantics, 
because  the  meaning  of  a  schema  involved  not  only  the  components  of  the  schema,  but  also 
the  global  variables  to  which  the  schema  might  refer. 
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9.7  Schema  disjunction 

The  schema  disjunction  Si  V  Sj  is  a  schema  whose  signature  is  the  join  of  the  signatures  of  the  two 
schemas  Si  and  S2  and  whose  property  is  the  disjunction  of  the  two  schemas’  properties. 

Abstract  syntax  A  schema  disjunction  is  composed  of  two  schemas. 

SDISJUNCTION  =  SCHEMA  V  SCHEMA 


Concrete  form 

Expression  OR  Expression 

Sample  representation  and  transformation 


Representation 

Abstract 

SiV  S2 

Type  The  signature  of  a  schema  disjuinction  Si  V  S^  is  the  join  of  the  two  schemas  Si  and  S^  : 

{S1VS2V  =  {{SiVds^V)’^^ 

Note:  The  schema  disjunction  Si  V  S2  is  well-typed  only  if  the  signature  of  the  two 

schemas  5i  and  S2  are  type  compatible. 


Meaning  The  bindings  of  a  disjoined  schema  are  all  those  with  its  signature  which  are  extensions  of 
bindings  in  one  or  other  of  the  operand  schemas: 
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9.8  Schema  conjunction 

Abstract  syntax  A  schema  conjunction  is  composed  of  two  schemas 
SCONJUNCTION  =  SCHEMA  A  SCHEMA 


Concrete  form 

DeclElem  SEMICOLON  DeclElem  {SEMICOLON  DeclElem} 
Expression  AND  Expression 


Sample  representation  and  transformation 


Representation 

Abstract 

Di]  L>2;  Dn 

Si  A  S2 

iDif-,  p2f; 
iSifAiS^f 

Variables  may  be  introduced  in  local  schemas  more  than  once,  provided  that  they  have  the  same  type. 
Repeated  schemas  do  not  add  anything  to  the  signature;  however  the  constraint  of  the  repeated  schema 
is  conjoined  with  the  constraints  of  all  the  other  schemas. 


Type  The  signature  of  a  schema  conjunction  Si  A  Sa  is  the  join  of  the  two  schemas  Si  and  Sa: 
(  A  5^  =  {([  S,  ;  U 

Note:  The  schema  conjunction  Si  A  Sa  is  well-typed  only  if  the  two  schemas  Si  and  Sa 
are  well-typed  and  their  signatures  are  type  compatible. 


Meaning  The  bindings  of  a  conjoined  schema  are  all  those  with  its  signature  which  are  extensions  of 
bindings  in  both  of  the  operand  schemas: 

dSiASaT  =  {(5'ir,([Sar);Ll 

Note:  Spivey  (1988)  has  already  remarked  on  the  similarity  with  the  semantics  of  the 

parallel  composition  operator  in  the  traces  model  of  CSR 


Note:  Duplicated  schemas  are  significant  in  the  evaluation  of  the  characteristic  tuple.  The 
representative  term  can  be  a  list  of  terms  which  form  part  of  the  top  level  tuple. 
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9.9  Schema  implication 

Abstract  syntax  A  schema  implication  is  composed  of  two  schemas. 
SIMPLICATION  =  SCHEMA  SCHEMA 


Concrete  form 

Expression  IMPLIES  Expression 


Representation 

Abstract 

5i=»52 

(s.f=!-rs2f 

Type  The  signature  of  a  schema  implication  ^  is  the  join  of  the  two  schemas  and  : 

=  (([5,  r,([5.r)iLi 

Note;  The  schema  implication  is  well-typed  only  if  the  two  schemas  and 

are  well-typed  and  their  signatures  are  type  compatible. 


Meaning  The  meaning  of  the  schema  implication  Si  =>  is  the  same  as  the  meaning  of  the  schema 
disjunction  V  Sa- 

{  Si  ^  82}^  =  ([  “«  Si  V  1S2 
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9.10  Schema  equivalence 

Abstract  syntax  A  schema  equivalence  is  composed  of  two  schemas. 
SEQUIVALENCE  =  SCHEMA  ^  SCHEMA 


Concrete  form 

Expression  IFF  Expression 


Sample  representation  and  transformation 


Representation 

Abstract 

5i  ^  S2 

lSlf^iS2f 

Type  The  signature  of  a  schema  equivalence  ^  S2  is  the  join  of  the  two  schemas  Si  and  : 

([5,^5,])^  =  (l[5, 

Note:  The  schema  equivalence  Si  ^  S2  is  well- typed  only  if  the  two  schemas  Si  and  S2 
are  well-typed  and  their  signatures  axe  type  compatible. 


Meaning  The  bindings  are  all  those  with  this  signature  which  are  extensions  of  bindings  in  neither 
or  both  of  the  operand  schema  expressions: 

=  {  S,  =i^  S2  A  S, 


Z  Notation  Version  1.1  30th  June  1995 


93 


9  SCHEMA 


9.11  Schema  projection 

The  schema  projection  operator  (f)  hides  all  the  components  of  its  first  argument  except  those  which 
are  also  components  of  its  second  argument. 

Abstract  syntax  A  schema  projection  is  composed  of  two  schemas. 

SPROJECTION  =  SCHEMA  Proj  SCHEMA 


Concrete  form 

Expression  PROJECTION  Expression 
Sample  representation  and  transformation 


Representation 

Abstract 

S\T 

Type  The  signature  of  a  projection  Sx  \  includes  those  names  in  both  the  domains  of  the  signatures 
of  Sx  and  The  type  given  to  each  such  name  is  taken  from  Sj.  Note  that  if  names  are  given  types 
by  both  Si  and  S2  those  types  must  be  the  same  (that  is,  the  signatures  must  be  consistent): 

(5,  \  s,  r  = 


Meaning  The  value  of  the  projection  Si  \  is  the  set  of  bindings  which  satisfy  Si ,  restricted  to  the 
alphabet  of  S2: 

(5,  r5,  r  =  r45.ro  5  n 

Note:  Spivey  (1988)  gives  two  forms  of  projection  operator  used  in  a  schema  expression 
such  as  Si  f  S2 .  The  weak  operator  hides  those  components  of  Si  which  axe  not  in  the 
signature  of  S2.  The  strong  form  requires  the  components  to  satisfy  the  axioms  of  S2  as 
well.  We  give  the  semantics  for  the  weak  operator. 
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9.12  Schema  hiding 

The  hiding  operator  (\)  takes  a  schema  expression  as  its  first  operand  and  an  identifier  list  as  its 
second  operand.  The  result  is  a  schema  expression  whose  components  are  those  of  the  operand  schema 
excluding  those  named  in  the  list. 

Abstract  syntax  A  hidden  schema  is  composed  of  a  schema  and  a  list  of  names. 

SHIDING  =  SCHEMA  \  [NAME, NAME] 


Concrete  form 

Expression  HIDING  BRA  NameListl  KET 


Sample  representation  and  transformation 


Representation 

Abstract 

isf\<  ni,n2,...,nm  > 

Type  The  signature  of  a  schema  hiding  expression  is  the  signature  of  S  with  the  names  from  (rii , . . . ,  n,n 
removed.  Note  that  (rii, . . . ,  Um)  may  contain  names  not  in  the  signature  of  se: 

([  S  \  (rii, . . . ,  rim)  ])  =  ([  ‘S'  ])^  ?  ({^1 5  •  •  •  5 

Meaning  The  value  of  the  schema  S  in  which  the  components  (ni, . . . ,  rim)  have  been  hidden  is  the 
set  of  bindings  which  satisfy  S,  with  those  components  removed: 

([  S  \  (tIi,  .  .  .  rim)  ])  =  ([  S  ])  9  ({^D  •  •  • 

Note:  If  all  the  variables  are  hidden  the  result  is  a  schema  with  an  empty  signature. 
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9.13  Schema  universal  quantification 

Abstract  syntax  A  schema  quantification  is  constructed  from  a  schema  text  and  a  schema. 
SUNiVQUANT  =  VSCHEMA  •  SCHEMA 


Concrete  form 

EXISTS  TextOrExpression  DOT  Expression 


Sample  representation  and  transformation 


Representation 

Abstract 

VSt  •  s 

Type  The  signature  of  a  universally  quantified  schema  expression  V  5t  •  5  is  the  signature  of  S  with 
the  names  from  the  signature  of  St  removed: 


Note:  The  signature  is  well-typed  only  when  St  and  S  is  are  well-typed  and  their  signatures 
are  compatible. 


Meaning  The  value  of  a  universally  quantified  schema  expression  V  St  •  5  is  the  set  of  bindings  with 
the  defined  signature  such  that,  for  all  bindings  of  St,  the  union  of  the  two  bindings  is  an  extension  of 
S: 


(VSt.S])^  =  K-BSt  • -.S])^ 

Note:'  Note  that  this  definition  takes  advantage  of  de  Morgan’s  Law. 
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9.14  Schema  existential  quantification 

Abstract  syntax  A  schema  quantification  is  composed  of  a  schema  text  and  a  schema. 
SEXISTSQUANT  =  3  SCHEMA  •  SCHEMA 


Concrete  form 

EXISTS  TextOrExpression  DOT  Expression 


Sample  representation  and  transformation 


Representation 

Abstract 

3St0S 

3[Stf'r0lsf 

Type  The  signature  of  an  existentially  quantified  schema  expression  3  •  5  is  the  signature  of  S 

with  the  names  from  the  signature  of  St  removed: 

{Bst.sr  = 

Note:  The  signature  is  well-typed  only  when  St  and  5  is  are  well-typed  and  their  signatures 
are  compatible. 


Meaning  The  value  of  an  existentially  quantified  schema  expression  3  St  0  S  is  the  set  of  bindings 
with  signature  of  S  less  St,  such  that  there  is  a  binding  of  St  so  that  the  union  of  the  two  bindings  is 
an  extension  of  S: 

i3St0S}^  =  {{S])^,{{St)}^ 

Note:  This  definition  should  be  contrasted  with  the  analogous  expression  for  predicates 
{3  St  •  p)  where  the  well- typing  of  the  predicate  is  decided  in  the  modified  environment. 
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9.15  Schema  unique  existential  quantification 

Abstract  syntax  A  schema  quantification  is  composed  of  a  schema  text  and  a  schema. 
SUNIQUEQUANT  =  3^^  SCHEMA  •  SCHEMA 


Concrete  form 

EXISTSl  Text Or Expression  DOT  Expression 


Sample  representation  and  transformation 


Representation 

Abstract 

•  5 

Type 


i3,st.sr  =  (csr,([<st>r)?^ 

Note;  The  signature  is  well-typed  only  when  St  and  5  is  are  well-typed  and  their  signatures 
are  compatible. 

Meaning  The  value  of  an  existentially  quantified  schema  expression  3  ^  St  •  5  is  the  set  of  bindings 
with  signature  of  S  less  St,  such  that  there  exists  a  unique  binding  of  St  so  that  the  union  of  the  two 
bindings  is  an  extension  of  S: 

([  3,  St  •  S  ])^  =  To  be  defined 
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9.16  Schema  renaming 

The  renaming  operation  S[new/old]  substitutes  the  new  variable  name  for  the  old  in  the  schema. 


Abstract  syntax  A  schema  renaming  consists  of  a  schema  and  a  renaming  list. 
SRENAMING  =  SCHEMA  [NAME/NAME, NAME/NAME] 


Concrete  form 

Expression  SQBRA  RenameList  SQKET 


Sample  representation  and  transformation 


Representation 

Abstract 

S[xilyuX2ly2,---Xnlyn] 

^  ®i/yi9  ^2/2/25  •  •  •  ®n/2/n  ^ 

Type  Schema  renaming  changes  the  names  of  the  elements  in  the  bindings,  and  hence  the  signature. 
{S[Nl]}^  =  0  1) 

Meaning 

{S[Nl]])^  =  ([  S  ;  3({  0  1) 

Note;  When  more  than  one  variable  is  to  be  substituted,  the  substitution  is  simultaneous. 

Any  substitutions  for  non-existent  names  are  ignored.  Each  old  name  can  only  be  substituted 
by  one  new  name.  Likewise,  each  new  name  can  be  a  substitute  for  only  one  old  name. 
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9.17  Substituted  schema 

The  meaning  of  the  substituted  schema  boS  is  the  same  as  the  meaning  of  the  schema  S  in  the 
environment  enriched  by  the  binding  h. 

Abstract  syntax  A  substituted  schema  is  composed  of  an  expression  and  a  schema. 
SSUBSTITUTION  =  EXP  ©  SCHEMA 


Concrete  form 

Expression ,  ‘  o’  ,  Schem  a 


Sample  representation  and  transformation 


Production 

Representation 

Abstract 

boS 

ibfoiSf 

beSt 

beD 

ibfolDf 

Type  The  signature  of  the  substituted  schema  6©5  is  the  signature  of  the  schema  S  in  the  type- 
environment  enriched  by  the  binding  h. 

([  60S  Y  =  (1>  I  ^  F  ?  schemaT~^)  5  ©  ?  ([  S 

A  substituted  schema  is  well-typed  if  and  only  if  the  binding  is  well-typed  and  the  schema  is  well-typed 
in  the  enriched  environment. 


Meaning  The  situations  of  the  substituted  schema  60S  are  the  situations  of  the  schema  S  in  the 
environment  enriched  by  the  binding  6. 

{beS])^  =  (1,1  61^  |©5([  5}^ 
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Editor’s  note:  Revised  versions  of  the  following  subsections  have  been  included  in  Annex  F.  The  logical 
theory  of  Z. 


Free  variables 
Substitution 
□ 
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Paragraph 


Notes  on  this  section  of  the  Z  Standard 
Section  title:  Paragraph 

Section  editor:  Peter  Lupton  (this  version  edited  by  JEN) 
Original  text  by:  Stephen  Brien 

Contributions  by:  Stephen  Brien,  . . .  (others  to  be  added) 

Source  file:  par.tex 

Most  recent  update:  21st  June  1995 

Formatted:  3rd  July  1995 


Editor’s  note:  This  is  a  revision  of  the  Paragraph  section,  incorporating  the  proposed  new  Concrete 
Syntax  in  a  provisional  form.  The  section  will  be  updated  and  revised  by  Peter  Lupton. 


10,1  Introduction 

Each  paragraph  of  Z  can  do  two  things:  Augment  the  environment  by  a  declaration  and  strengthen  the 
property  by  a  predicate.  Each  paragraph  is  considered  as  a  relation  between  environments.  The  domain 
of  this  relation  contains  all  the  environments  in  which  the  paragraph  is  well-typed  and  any  predicates 
contained  within  it  are  true.  These  environments  are  related  to  those  which  include  the  new  variables 
declared  in  their  signature  and  which  satisfy  any  property  denoted  by  the  paragraph. 

(PAR  :  Tenv  H-f  Tenv 

(PAR  :  Env  Env 

We  can  prove  the  following 

h  {Par  ?  T  C  T  ?  {Par 


Abstract  Syntax 

PAR  =  GIVENSETDEF 
I  GLOBALPRED 
1  GLOBALSCHEMA 
I  GENERICSCHEMA 
I  GLOBALDEF 
I  GENERICDEF 
I  CONJECTURE 
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Given  sets 


10.2  Given  sets 

The  given  set  definition  [  Xi,  X2, . . .  ,Xn  ]  introduces  the  sets  Zi, Z2, . . . ,  without  determining 
their  elements. 

Note:  Distinctly  named  given  sets  have  distinct  types  and  hence  are  incomparable. 

Abstract  syntzoc 

GIVENSETDEF  =  given  [NAME,  NAME, NAME] 


Concrete  form 

SQBRA  NameListl  SQKET 


Sample  representation  and  transformation 


Representation 

Abstract 

[XuX2,...,Xn] 

given  {Xi,...,Xn) 

Type  The  declaration  of  given  sets  given [Xi, ...,  Zn]  causes  the  type  environment  to  be  suitably 
enriched.  Each  name  is  given  the  power  set  type  of  the  given  type  of  that  name.  These  declarations 
over-ride  the  environment. 

Note  that  a  given  set  definition  of  N  results  in  N  having  the  type  powerT  givenT  N 
{given(Xi, . . . ,  Xn)  =  (1,  ({A'l, . . . ,  Xn}  <  givenT  5  powerT^)  ;  0 


Meaning  To  enrich  the  meaning  environment,  we  construct  a  binding  of  the  given  set  names  (those 
in  ran  5)  to  typed  values  in  the  world  of  sets  -  for  this  to  be  correct,  the  bindings  must  be  such  that 
the  given  sets  do  indeed  have  power  set  type.  The  environment  is  updated  with  this  binding. 

{given(Xi, . . . ,  Xn)  =  (1,  ({Ai, . . . ,  Xn}  <  givenT  ;  {powerT,  Carrier))^)  ;  0 
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10.3  Constraint 

A  constraint  is  a  predicate  appearing  on  its  own  as  a  paragraph.  It  denotes  a  property  of  the  values  of 
variables  declared  elsewhere  with  global  scope.  This  property  is  conjoined  to  the  global  property. 


Abstract  syntax 

GLOBALPRED  =  where  PRED 


Concrete  form 
Predicate 


Sample  representation  and  transformation 


Representation 

Abstract 

p 

where[Pj^ 

Type  A  constraint  adds  nothing  to  the  environment,  so  it  is  that  subset  of  the  identity  relation 
restricted  to  the  environments  in  which  the  predicate  is  true. 

For  the  type  environment: 


Meaning  For  meaning  environment: 


{pr 
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10-4  Global  declaration 

An  axiomatic  definition  introduces  variables  and  specifies  further  properties  of  the  elements  denoted  by 
them. 


Abstract  syntax 

GLOBALSCHEMA  =  def  SCHEMA 


Concrete  form 

AX  [DeclPart  I  Expression]  [ST  Predicate]  END 
‘AX’  , DeclPart,  ‘END’ 


Sample  representation  and  transformation 


Representation 

Abstract 

‘AX’  D  ‘ST’  P‘END’ 

‘AX’  D  ‘END’ 

defpf  \iPf 
deflD}^  1  true 

The  abstract  form  of  an  axiomatic  definition  is  a  pair  of  paragraphs,  one  containing  a  declaration  and 
the  other  a  predicate.  If  the  Axiom  Part  is  omitted  the  the  abstract  form  is  one  declaration  paragraph. 


Type  When  new  variables  are  declared  the  environment  is  enriched  by  a  function  from  their  names 
to  one  from  their  empty  generic  parameter  list  to  their  meaning.  We  give  as  its  value  a  set  of  bindings, 
one  for  each  name  declared.  In  obtaining  the  binding,  we  enrich  the  environment  with  the  declaration 
in  such  a  way  that  the  constraint  is  satisfied.  The  names  in  the  declaration  are  bound  to  their  values 
in  this  enriched  environment.  Formally: 

(defjD  \py  =  {D\py 
Meaning 

(defD  \P]^  =  {D\P}^ 

Note:  The  sets  from  which  the  elements  denoted  by  the  variables  can  be  drawn  are  defined 

by  the  conjunction  of  the  constraint  of  the  DeclPart  and  the  property  in  the  Axiom  Part. 

The  signature  of  the  DeclPart  is  joined  to  the  global  signature.  The  constraint  in  the 

DeclPart  and  the  property  of  the  Axiom  Part  are  conjoined  to  the  global  property. 
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10.5  Generic  declarations 

A  generic  declaration  of  variables  adds  these  variables  to  the  dictionary  and  maps  them  to  a  function 
from  all  possible  instantiations  of  their  generic  parameters  to  the  values  of  the  variables  with  these 
instantiations. 


Abstract  syntax 

GENERICSCHEMA  =  gendef  [NAME,  NAME, . . . ,  NAME]  const  SCHEMA 


Concrete  form 

GEN  [Formals]  BAR  [DeclPart  I  Expression]  [ST  Predicate]  END 
‘  GEN’ )  Gen  Form  a  Is /BAR’ ,  DeclPart /END’ 

Sample  representation  and  transformation 


Representation 

Abstract 

‘GEN’  [Xi,X2,. 
‘GEN’  [Xi,X2,. 

.,X„]‘BAE’  ‘SI’  P‘END’ 

.,Xn  ]‘BAR’  D  ‘END’ 

gendef  {  Xi,  Xj, . . . ,  X„  )  const^jOj®  where  {P'f’ 
gendef  (  Xj,  Xa, . . . ,  X„  )  const[I>J®  where  true 

Type 


Value  A  generic  declaration  introduces  a  family  of  variables,  parametrised  by  the  generic  parameters 
of  the  list  Gen  Form  a  Is. 


Note;  In  a  GenericDef,  the  DeclPart  declares  the  names  of  the  generic  variables  whose 
types  can  be  determined  upon  instantiation  of  the  formal  parameters.  The  predicate  in  the 
Axiom  Part  determines  the  elements  denoted  by  the  variables  for  each  value  of  the  formal 
parameters. 

Recursive  generic  declarations  are  not  allowed.  The  generic  declaration  must  not  place  any 
restriction  on  the  generic  parameters. 

A  generic  variable  has  global  scope,  excluding  the  declaration  list  in  which  it  is  declared  and 
any  construct  in  which  its  name  is  re-used  for  a  local  variable. 

The  parameters  of  a  generic  declaration  are  local  to  the  declaration,  but  they  can  be  instan¬ 
tiated  by  elements  of  set  type  when  the  generic  variable  is  used. 
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A  generic  declaration  does  not  give  a  single  type:  rather,  a  function  from  the  generic  pa¬ 
rameters  to  types  is  defined. 

Let  X  and  Y  be  generic  formal  parameters  and  consider  a  generic  declaration  which  declares 
X  :  X;  y  :  Y.  Then  an  expression  such  asx^y  or  x  =  y  would  impose  a  mutual  constraint 
on  the  types  that  could  be  used  to  instantiate  X  and  Y.  For  x  £  y,  we  have  the  constraint 
that  the  types  that  Y  may  take  are  the  powerset  of  the  types  that  X  may  take;  for  x  =  y, 
we  have  the  constraint  that  the  types  that  Y  may  take  must  be  the  same  as  the  types  that 
X  may  take. 

The  definition  of  generic  types  as  total  functions  imposes  the  constraint  that  generic  dec¬ 
larations  do  not  create  relationships  between  the  type  of  their  formal  parameters.  Such 
relationships  can  always  be  efiminated  within  a  specification. 

Since  all  the  type  constructors  axe  bijections,  any  relationship  between  the  types  of  generic 
parameters  is  functional.  Therefore  any  dependent  parameters  are  redundant  since  they  can 
be  uniquely  determined  as  functions  of  the  other  parameters.  For  instance,  for  x  £  y  the 
relationship  can  be  eliminated  by  removing  F  as  a  formal  generic  parameter  and  defining 
j/ :  P X;  for  x  =  y  we  can  eliminate  Y  and  define  y  :  X. 
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10.6  Global  definitions 
Abstract  syntax 

GLOBALDEF  =  abbr  NAME  :=  EXP 


Concrete  form 

SCH  NAME  [Formals]  IS  [DeclPart  I  Expression]  [ST  Predicate]  END 
‘SCH’  ,  SchemaName,  ‘IS’  ,  DeclPart,  ‘ST’,  Axiom  Part,  ‘END’ 

‘SCH’  ,  SchemaName,  ‘IS’  , DeclPart,  ‘END’ 

Ident,  ‘==’  ,  Expression 


Sample  representation  and  transformation 

Note:  A  Global  Definition  defines  a  new  schema.  There  are  two  forms  for  a  schema 

definition.  The  horizontal  is  the  primary  form.  The  vertical  form,  using  a  schema  box,  is 
given  a  meaning  in  terms  of  an  equivalent  horizontal  definition. 


Representation 

Abstract 

Type  When  a  schema  or  variable  is  declared  the  name  is  added  to  the  type-environment  and  is 
mapped  to  the  type  of  the  schema  or  expression. 

(abbriV  =  Xr  =  5  {-});© 


Meaning  When  a  schema  or  variable  is  declared  the  name  of  the  schema  is  added  to  the  environment 
and  is  mapped  to  the  meaning  of  the  schema  or  expression. 

(abbrivaxr  =  (l,(iVMXD  ;{-});© 

Note: 

•  The  horizontal  form  of  the  definition  defines  the  schema  with  name  SchemaName  as 
the  schema  denoted  by  the  SchemaExpr. 
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•  The  vertical  form  of  the  definition  defines  the  schema  with  name  SchemaName  as  the 
schema  denoted  by  the  schema  expression  constructed  from  the  schema  text  comprising 
the  horizontal  equivalents  of  the  DecIPart  and  the  Axiom  Part  (see  Vertical  Form). 

A  SchemaName  may  be  used  to  define  only  one  schema  within  a  specification. 

A  Schema  has  global  scope  except  within  the  text  of  its  definition.  Recursive  schema  def¬ 
initions  are  not  allowed.  The  scope  of  variables  introduced  in  the  DecIPart  is  local  to  the 
SchemaDef  and  includes  the  Axiom  Part. 
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10.7  Generic  definition 

A  generic  definition  of  variables  adds  these  variables  to  the  environment  and  maps  them  to  a  function 
from  all  possible  instantiations  of  their  generic  parameters  to  the  values  of  the  variables  with  these 
instantiations. 


Abstract  syntax 

GENERICDEF  =  abbr  NAME[NAME,  NAME, ...,  NAME]  :=  EXP 


Concrete  form 

NAME  [Formals]  DEFINE-EQUAL  Expression 
Sample  representation  and  transformation 


Representation 

Abstract 

Type 

|abbriV[5i , . . . ,  Sm]  =  X  = 

{ 

1, 

A((l,  Ptype°  ;9), . . . ,  {Sm°,  Ptype°  |9))  ?  {. . .}))  ;  ^({{I  f).  I  X  f )) 

);e 


Value 

Note: 

In  a  Generic  Definition,  the  DecIPart  declares  the  names  of  the  generic  variables  whose  types 
can  be  determined  upon  instantiation  of  the  formal  parameters. 

An  abbreviation  definition  can  be  used  to  define  a  possibly  generic  variable  which  is  named 
by  an  identifier  Abbrev. 

The  variable  defined  by  the  expression  can  take  three  forms: 
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•  Possibly  Generic  Variable  Ident. 

•  Prefix  Generic  Symbol  PreGen. 

•  Infix  Generic  Symbol  In  Gen. 

In  the  latter  two  cases,  the  names  of  the  generic  parameters,  Word  indicate  the  posi¬ 
tions  of  the  actual  parameters  which  can  be  supplied  when  the  variables  are  used. 

A  schema  may  be  defined  with  generic  parameters  and  when  used  it  must  be  always 
instantiated. 
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10.8  Conjecture 
A  new  section  -  text  to  be  added. 


Abstract  syntax 

CONJECTURE  =  conj  SCHEMAf . . .  fSCHEMA  |  PRED, . . . ,  PRED  h  PRED, . . 


. ,  PRED 
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Notes  on  this  section  of  the  Z  Standard 

Section  title:  Specification 
Source  file:  spc.tex 
Section  editor: 

Original  text  by:  Stephen  Brien 
Contributions  by: 

Most  recent  update:  30th  June  1995 
Formatted:  3rd  July  1995 


Editor’s  note: 

This  section  has  not  been  revised.  It  will  be  re-written  when  the  current  discussions  on  semantics,  which 
affect  this  section  and  the  section  on  Paragraph,  have  been  completed. 


11,1  Introduction 

A  specification  is  constructed  from  a  sequence  of  paragraphs: 

Abstract  syntax 

SPEC  =  PAR  PAR 


Sample  representation  and  transformation 


Production 

Representation 

Abstract 

[Paragraph]  , 

{Narrative ,  Paragraph} , 

[Narrative] 

Pi  Narrative . . .  Narrative 

Type  A  specification  is  well-typed  if  the  empty  type  environment  is  in  the  domain  of  the  typing 
relation. 


113 


Z  Notation  Version  1,1  30th  June  1995 


11  SPECIFICATION 


Meaning  The  meaning  of  a  specification  is  the  set  of  environments  which  are  related  to  the  empty 
environment  by  the  paragraphs  of  the  text.  These  are  all  the  environments  which  are  enrichments  of  the 
empty  environment  by  the  specification.  A  sequence  of  paragraphs  can  be  composed  together.  They 
denote  a  relation  between  environments.  This  relation  is  the  sequential  composition  of  the  relations 
denoted  by  the  individual  paragraphs. 

zmnPiand . . .  andPn  =  ^{{Pi  5  •  •  •  ?  {Pn 


Note  A  Z  specification  consists  of  a  sequence  of  paragraphs  separated  by  paragraph  separators.  These 
paragraph  separators  may  include  explanatory  text  The  global  signature  and  property  are  constructed 
from  the  meanings  of  these  paragraphs. 

A  paragraph  is  either  a  definition  or  a  constraint. 

A  definition  introduces  Basic  types,  schemas,  or  variables  (named  elements,  sets  tuples  or  bindings) 
together  with  constraints  on  them.  The  effect  of  a  definition  is  to  augment  the  global  signature  and  to 
conjoin  its  constraint  with  the  global  property. 

A  constraint  denotes  a  property  on  variables  and  schemas  declared  elsewhere.  The  effect  of  a  constraint 
is  to  conjoin  its  property  with  the  global  property. 

A  specification  is  well  typed  if  every  term  and  predicate  within  the  paragraphs  is  well  typed. 

□ 
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Notes  on  this  section  of  the  Z  Standard 
Section  title;  Abstract  syntax 

Note:  This  version  of  the  Abstract  syntax  is  based  on  ZSRC  Document 
z-159v2.tex,  with  amendments  agreed  at  Meeting  23  of  the  Z  Standards 
Panel  on  27th  September  1994. 

Section  editor:  John  Nicholls 
Contributions  by;  (to  be  added) 

Source  file;  absyn.tex 

Most  recent  update;  29th  May  1995  (minor  update) 

Formatted;  3rd  July  1995 


A.l  Introduction 

Basis  of  definition.  The  abstract  syntax  is  central  to  the  definition  of  Z.  It  stands  between  the 
concrete  representations  of  Z  documents  -  as  marks  on  paper  and  images  on  screens  -  and  the  abstract 
entities,  semantic  relations  and  semantic  functions  used  for  defining  their  meaning. 

There  are  many  possible  ways  of  constructing  an  abstract  syntax  for  Z,  and  the  choice  of  the  form 
given  below  is  a  matter  of  judgement,  taking  into  account  the  somewhat  conflicting  aims  of  simplicty 
and  economy  of  semantic  definition,  and  the  maintenance  of  a  clear  relationship  with  the  concrete 
representation. 

The  abstract  syntax  has  the  following  objectives: . 

to  identify  and  separately  name  the  distinct  categories  of  the  notation. 

to  simplify  and  unify  the  underlying  concepts  of  the  notation,  putting  like  things  with  like,  and 
reducing  unnecessary  duplication. 


The  syntax  is  presented  as  a  set  of  production  rules,  in  which  each  entity  is  defined  in  terms  of  its 
constituent  parts.  For  each  of  the  entities  defined  in  the  abstract  syntax,  there  is  a  subsection  in  the 
main  part  of  the  Base  Standard,  defining  its  representation  and  meaning. 


Z  Notation  Version  1.1  30th  June  1995 


115 


A  ABSTRACT  SYNTAX  -  NORMATIVE  ANNEX 


Metalanguage.  The  definition  uses  the  following  notation: 

::=  definition  symbol 

I  disjunction  symbol 

Several  definitions  contain  lists  of  entities,  separated  by  commas  or  other  separating  characters.  Where 
there  may  be  an  arbitrary  number  of  entities  in  such  a  list,  the  following  notation  is  used: 

ellipsis,  denoting  a  finite  (possibly  zero)  number  of  occurrences  of  the  preceding  entity, 
together  with  appropriate  separators 


Terminal  entities.  The  terminal  entities  of  the  definition  are  semantic  entities,  written  in  uppercase 
sans-serif  font. 

In  addition,  the  syntax  definitions  contain  operators,  symbols  and  keywords  similar  to  those  used  in  the 
concrete  syntax.  These  are  written  in  this  way  to  indicate  the  relationship  of  each  abstract  definition 
with  the  concrete  form  of  the  notation. 

The  relationship  between  the  abstract  and  concrete  forms  of  each  entity  is  indicated  in  the  entity 
definitions  in  the  main  body  of  the  standard,  under  the  headings  “Representation  and  transformation”. 


Changes  in  this  version.  The  following  changes  have  been  made  to  the  Abstract  Syntax  since  the 
version  published  in  Version  1.0. 

Structural  changes: 

the  previously  separate  entity  Schematext  has  been  removed  and  merged  with  Schema. 

a  new  rule  has  been  introduced  allowing  an  expression  to  be  written  wherever  a  schema  (or  what 
was  previously  called  schematext)  is  allowed.  Such  an  expression  must  be  suitably  typed;  it  should 
be  noted  that  type  information  is  not  expressed  in  the  Abstract  Syntax. 

the  entity  Compound  Schema  has  been  removed  from  the  Abstract  Syntax.  The  semantics  of 
Compound  Schema  is  defined  in  terms  of  Schema  Conjunction. 

the  entities  Schema  Designator  (SDES)  and  Generic  Schema  Designator  (SGENDES)  have  been 
removed. 

Changes  in  presentation: 


a  more  uniform  convention  for  naming  syntactic  entities  has  been  introduced, 
the  order  of  presentation  has  been  modified. 
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A.  2  Specification 

SPEC  =  PAR  PAR 


A.3  Paragraph 
PAR 


GIVENSETDEF 

GLOBALPRED 

GLOBALSCHEMA 

GENERICSCHEMA 

GLOBALDEF 

GENERICDEF 

CONJECTURE 


GIVENSETDEF 

GLOBALPRED 

GLOBALSCHEMA  = 

GENERICSCHEMA  = 

GLOBALDEF 

GENERICDEF 

CONJECTURE 


given  [NAME,  NAME, . . . ,  NAME] 
where  PRED 
def  SCHEMA 

gendef  [NAME,  NAME, . . . ,  NAME]  const  SCHEMA 
abbr  NAME  :=  EXP 

abbr  NAME[NAME,  NAME, ...,  NAME]  :=  EXP 

conj  SCHEMAt . . .  tSCHEMA  j  PRED, . . . ,  PRED  h  PRED, . . . ,  PRED 
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A.4  Schema 

SCHEMA  =  SDECL 

I  SCONSTRUCTION 
I  SNEGATION 
I  SDISJUNCTION 
1  SCONJUNCTION 
1  SIMPLICATION 
I  SEQUIVALENCE 
1  SPROJECTION 
1  SHIDING 
1  SUNIVQUANT 
I  SEXISTSQUANT 
I  SUNIQUEQUANT 
1  SRENAMING 
I  SCOMPOSITION 
I  SDECORATION 
I  SSUBSTITUTION 
I  EXPSCHEMA 


SDECL 

SCONSTRUCTION  = 
SNEGATION 
SDISJUNCTION 
SCONJUNCTION  = 
SIMPLICATION 
SEQUIVALENCE  = 
SPROJECTION 
SHIDING 
SUNIVQUANT 
SEXISTSQUANT  = 
SUNIQUEQUANT  = 
SRENAMING 
SCOMPOSITION  = 
SDECORATION 
SSUBSTITUTION  = 
EXPSCHEMA 


NAME,  NAME, . . . ,  NAME  :  EXP 
SCHEMA  I  PRED 
SCHEMA 

SCHEMA  V  SCHEMA 

SCHEMA  A  SCHEMA 

SCHEMA  SCHEMA 

SCHEMA  SCHEMA 

SCHEMA  Proj  SCHEMA 

SCHEMA  \  [NAME,...,  NAME] 

VSCHEMA*  SCHEMA 

3  SCHEMA  •SCHEMA 

3,  SCHEMA  •SCHEMA 

SCHEMA  [NAME/NAME, . . . ,  NAME/NAME] 

SCHEMA  I  SCHEMA 

SCHEMA  DECOR 

EXP  o  SCHEMA 

EXP 
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A.  5  Predicate 
PRED 


EQUALITY 

MEMBERSHIP 

TRUTH 

FALSEHOOD 

NEGATION 

DISJUNCTION 

CONJUNCTION 

IMPLICATION 

EQUIVALENCE 

UNIVERSALQUANT 

EXISTSQUANT 

UNIQUEQUANT 

SPRED 

PREDSUBSTITUTION 
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=  EQUALITY 
I  MEMBERSHIP 
I  TRUTH 
I  FALSEHOOD 
I  NEGATION 
I  DISJUNCTION 
I  CONJUNCTION 
I  IMPLICATION 
I  EQUIVALENCE 
I  UNIVERSALQUANT 
I  EXISTSQUANT 
I  UNIQUEQUANT 
I  SPRED 

I  PREDSUBSTITUTION 


=  EXP  =  EXP 
=  EXP  e  EXP 
=  true 
=  false 
=  PRED 
=  PRED  V  PRED 
=  PRED  A  PRED 
=  PRED  PRED 

=  PRED  PRED 

=  VSCHEMAePRED 
=  3 SCHEMA*  PRED 
=  3j  SCHEMA  •PRED 
=  SCHEMA 
=  EXPoPRED 


1995 
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A.  6  Expression 

EXP  =  IDENT 

I  GENINST 
I  NUMBERL 
I  STRINGL 
I  SETEXTN 
I  SETCOMP 
I  POWERSET 
I  TUPLE 
I  PRODUCT 
I  TUPLESELECTION 
I  BINDINGEXTN 
I  THETAEXP 
I  SCHEMAEXP 
I  BINDSELECTiON 
I  FUNCTAPP 
I  DEFNDESCR 
I  IFTHENELSE 
I  EXPSUBSTITUTION 


IDENT 

GENINST 

NUMBERL 

STRINGL 

SETEXTN 

SETCOMP 

POWERSET 

TUPLE 

PRODUCT 


=  NAME 

=  NAME  [EXP,  EXP, . . . ,  EXP] 
=  NUMBER 
=  STRING 

=  {EXP,  EXP, . . . ,  EXP} 

=  {SCHEMA  •EXP} 

=  PowEXP 
=  (EXP,  EXP, . . . ,  EXP) 

=  EXP  X  EXP  X  ...  X  EXP 


TUPLESELECTION  =  EXP  .  NUMBERL 

BINDINGEXTN  =  d  NAME  :=  EXP, ...,  NAME  :=  EXP^ 

THETAEXP  =  e  SCHEMA  DECOR 


SCHEMAEXP  =  SCHEMA 


BINDSELECTION 

FUNCTAPP 

DEFNDESCR 

IFTHENELSE 


=  EXP  .  NAME 
=  EXP  (EXP) 

=  At  SCHEMA  •EXP 
=  if  PRED  then  EXP  else  EXP  fi 


EXPSUBSTITUTION  =  EXP  o  EXP 
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A.7  Name 

NAME  =  WORD  DECOR,  ...  , DECOR 

□ 
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Notes  on  this  section  of  the  Z  Standard 
Section  title:  Concrete  syntax 

Note:  This  version  of  the  syntax  is  based  on  the  proposal  by  Will  Harwood 
and  Pete  Steggles  (Document  173  dated  6th  March  1995). 

Section  editor:  John  Nicholls 

Contributions  by:  Will  Harwood,  Pete  Steggles,  Chris  Sennett,  Rob 
Arthan,  Stephen  Brien,  . . .  (more  to  be  added) 

Source  file:  concrete.tex 

Most  recent  update:  30th  June  1995 

Formatted:  3rd  July  1995 


B.l  Introduction 

Editor’s  note:  This  Annex  and  the  Lexis  (Annex  C).  replace  the  section  previously  called  Representation 
Syntax. 

The  relationships  between  the  different  forms  of  syntax,  and  the  metalanguages  used  for  their  description, 
need  further  revision.  _  _ _ _ 

The  concrete  syntax  and  lexis  are  designed  to  meet  the  following  requirements: 

•  to  be  as  close  as  possible  to  ‘traditional’  Z; 

•  to  permit  the  substitution  of  equals  for  equals; 

•  to  make  unparsing  injective  (i.e.  different  legal  ASTs  should  have  different  unparsed  forms)  and 
total  (i.e.  there  should  be  a  concrete  syntax  for  every  legal  AST); 

•  to  make  it  convenient  to  project  representations  of  Z  and  enter  text  by  keyboard. 


Editor’s  note:  Further  notes  to  be  added  here  .  .  . 
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B.2  Syntactic  metalanguage 

The  concrete  syntax  and  lexis  are  defined  using  a  BNF  notation  based  on: 

BSI  Standard  BS  6154,  Method  of  defining  syntactic  metalanguage,  British  Standards  In¬ 
stitution,  1981. 

The  following  symbols  are  used: 

concatenate  symbol 
define  symbol 
definition  separator  symbol 
enclose  optional  syntactic  items 

enclose  syntactic  items  which  may  occur  zero  or  more  times 
enclose  terminal  symbols 
terminator  symbol  denoting  the  end  of  a  rule 
subtraction  from  a  set  of  terminals 
User  defined  rule 


Precedence.  The  concatenate  symbol  has  a  higher  precedence  than  the  definition  separator  symbol. 

Naming  conventions.  The  following  naming  conventions  are  used: 

•  terminals  are  fully  capitalized,  e.g.  ELSE. 

•  non-terminals  are  partly  capitalized,  e.g.  DeclPart. 


Editor’s  note:  Discuss  the  use  of  tt  typeface  here. 


Editor’s  note:  The  following  comment  is  taken  from  D-173  and  needs  to  be  noted  in  future  revisions: 

The  abstract  syntax  onto  which  this  syntax  is  targetted  is  a  slightly  modified  version  of  the  one  in  ZSRC 
Document  z-159.  The  changes  are  as  follows: 

•  EXP  can  be  an  option  of  SCHEMA. 

•  The  decoration  is  removed  from  THETAEXP, 

•  The  SCHEMASUBSTITUTION,  SDES,  GENSDES  options  are  removed. 
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B.3  Paragraph 
Peiragraph  = 

SQBRA  NameListl  SQKET 
I  Predicate 

I  AX  [DeclPart  I  Expression]  [ST  Predicate]  END 
I  GEN  [Formals]  BAR  [DeclPart  |  Expression]  [ST  Predicate]  END 
I  SCH  NAME  [Formals]  IS  [DeclPart  |  Expression]  [ST  Predicate]  END 
I  NAME  [Formals]  DEFINE.EQUAL  Expression 
1  TURNSTILE  Predicate 
I  NAME  FREEEQUALS  Branch  {VBAR  Branch} 

I  Fixity 

Formals  =  SQBRA  NameListl  SQKET 

Branch  =  NAME  [FREEBRA  Expression  FREEKET] 


The  top  level  paragraph  syntax  includes  given  set  definitions,  top  level  predicates,  all  the  boxes,  inline 
definitions,  goals  and  operator  template  definitions. 

The  tokens:  AX,  BAR,  END,  GEN,  IS,  SCH,  ST  have  special  graphical  conventions  associated  with 
them. 

Informal  text  is  treated  as  whitespace  by  the  lexer. 


Editor’s  note:  The  syntax  for  Specification  has  been  (temporarily)  omitted. 
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B.4  Fixity 


Editor’s  note:  In  later  versions,  the  descriptions  of  templates  and  fixity  may  be  moved  to  a  different 
place. 


Fixity  =  SYNTAX  Category  Template 

Operator  definitions  consist  of  a  Category  definition  and  Template  definition. 

Category  =  REL 

I  LEFT_FUN  Precedence 
I  RIGHT.FUN  Precedence 

The  Category  definition  indicates  whether  the  defined  operator  is  a  relation  (REL),  a  left  associative 
function  (LEFT_FUN)  or  a  right-  associative  function  (RIGHT_FUN).  Functions  also  have  a  numeric  prece¬ 
dence  defined. 

Precedence  =  NUMBER 

The  Precedence  definition  defines  the  precedence  of  the  declared  operator.  There  are  at  least  10000 
precedence  levels,  numbered  0  to  9999.  Higher  numbers  denote  higher  precedences. 

Template  =  [Arg]  NAME  {SeqArg  NAME}  [Arg] 

Arg  =  NORMAL 

I  TYPE 

SeqArg  =  Arg 

I  SEQUENCE  BRA  Expression  COMMA  Expression  COMMA  Expression  KET 

The  Template  definition  is  an  alternating  sequence  of  names  and  argument  slots.  There  are  three 
types  of  argument  slots:  NORMAL,  which  corresponds  to  the  argument  slots  in  current  Z  infix  and  prefix 
declarations;  TYPE,  which  declares  that  the  appropriate  argument  is  also  an  actual  generic  parameter  (so 
that  a  sequence  of  TYPE  parameters  corresponds  to  the  same-order  sequence  of  formal  generic  parameters 
of  the  operator  being  declared);  SEQUENCE,  which  is  an  argument  slot  for  a  comma-separated  list  of 
expressions. 

The  effect  of  a  syntactic  template  definition  is: 

•  to  assign  suitable  lexical  status  to  the  tokens  which  occur  in  the  template. 

•  to  assert  the  existence  of  a  ‘compound  symbol’  which  represents  the  template. 

•  to  assign  an  appropriate  precedence  and  associativity  to  this  compound  symbol. 

•  to  retain  information  about  this  symbol  sufficient  to  identify  it  as  a  relation  or  function  and  to 
cope  with  its  generic  instantiation  (if  it  has  TYPE  argument  slots). 
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The  following  token  categories  are  defined  (where  names  postfixed  with  P  represent  the  relational  version 
of  the  token  used  in  Predicate) 


I,  IP 

infix  token 

PRE,  PREP 

prefix  token 

POST,  POSTP 

postfix  token 

L,  LP 

initial  token 

EL,  ELP 

initial  token  preceded  by  expression 

ES 

separator  token  preceded  by  expression 

SS 

separator  token  preceded  by  expression  commalist 

ER,  ERP 

final  token  preceded  by  expression 

SR,  SRP 

final  token  preceded  by  expression  commalist 

ERE,  EREP 

final  token  preceded  by  expression  cind 
followed  by  expression 

SRE,  SREP 

final  token  preceded  by  expression  commalist  and 
followed  by  expression 

Any  attempt  to  redefine  the  lexical  status  of  a  token  is  an  error. 
Here  are  some  example  templates  with  descriptions  of  their  effects. 


SYNTAX  REL  small  NORMAL 
SYNTAX  REL  NORMAL  isodd 
SYNTAX  100  add  NORMAL  to  TYPE 

SYNTAX  50  add  SEQUENCE  ({>,makeSet,setUnion)  to  TYPE 
SYNTAX  RIGHT  900  ARG  a.normal.inf ix  ARG 


(small  =>  PREP) 

(isodd  =>  POSTP) 

(add  =>  L;  to  =>  ERE) 
(add  =>  L;  to  =>  SRE) 
(a_normal_infix  =>  I) 


The  sequence  argument  slot  includes  a  triple  of  a  zero,  unit  injection,  and  ‘union’  function,  which 
are  used  at  parse-time  to  construct  the  appropriate  expression  from  the  list  of  parsed  elements.  We 
choose  the  triple  including  union  because  the  three  constituents  are  generally  defined  for  most  generic 
collections  anyway. 
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B.5  Predicate 

Predicate  = 

Expression 

I  Predicate  CONJ  Predicate 
I  PRED  Expression 

I  EXISTS  TextOrExpression  DOT  Predicate 
I  EXISTSl  TextOrExpression  DOT  Predicate 
I  FORALL  TextOrExpression  DOT  Predicate 
I  Predicate  IFF  Predicate 
I  Predicate  IMPLIES  Predicate 
I  Predicate  OR  Predicate 
I  Predicate  AND  Predicate 
I  NOT  Predicate 
I  Relation 

I  Expression  SUBST  Predicate 
I  BRA  Predicate  KET 
I  TRUE 
I  FALSE 


Any  ambiguity  in  the  above  grammar  is  resolved  by  alloting  precedences  to  productions.  The  prece¬ 
dences  of  productions  increase  as  we  go  down  the  page.  All  relevant  operators  are  left-associative  apart 
from  IMPLIES  and  SUBST  which  are  right-associative. 

The  operators  should  all  be  familiar  except  CONJ.  This  is  a  low-precedence  conjunction  operator  which 
the  lexer  may  return  as  the  result  of  applying  some  layout  rule. 

B.5.1  Schemas  as  predicates 

Because  the  schema  expression  connectives  AND,  OR,  NOT  etc.  are  lexically  identical  to  the  predicate 
connectives,  we  need  a  way  of  clarifying  our  intentions  in  ambiguous  cases.  The  precedence  rules  above 
ensure  that  any  expression  involving  these  connectives  will  be  parsed  as  a  predicate  if  it  can  be;  to  force 
interpretation  as  a  schema  expression,  we  simply  prefix  an  expression  with  the  PRED  coercion  operator. 


B.5.2  Relation  application 

Relation  =  PrefixRel  Expression 
I  Expression  PostfixRel 

I  Expression  InfixRel  Expression  {InfixRel  Expression} 

I  NofixRel 

Relation  applications  axe  parsed  as  above,  using  the  extended  ‘grammar  for  operators’  which  uses  the 
tokens  defined  by  the  template  mechanism. 
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B.5.3  Relations 

PrefixRel  =  LP  {Expression  ES  I  ExpressionList  SS} 

(Expression  EREP  I  ExpressionList  SREP) 

I  PREP 

PostfixRel  =  ELP  {Expression  ES  I  ExpressionList  SS} 

(Expression  ERP  I  ExpressionList  SRP) 

I  POSTP 

InfixRel  =  ELP  {Expression  ES  I  ExpressionList  SS} 

(Expression  EREP  I  ExpressionList  SREP) 

I  IP 

I  MEMBER 
I  EQUALS 

NofixRel  =  LP  {Expression  ES  |  ExpressionList  SS} 

(Expression  ERP  I  ExpressionList  SRP) 

For  a  detailed  explanation  of  the  relation  ‘grammar  for  operators’  refer  to  the  appendix. 
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B.6  Expression  and  schema  expression 

Expression  = 

IF  Predicate  THEN  Expression  ELSE  Expression 
I  EXISTS  TextOrExpression  DOT  Expression 
I  EXISTS 1  TextOrExpression  DOT  Expression 
I  FORALL  TextOrExpression  DOT  Expression 
I  MU  TextOrExpression  DOT  Expression 
I  LAMBDA  TextOrExpression  DOT  Expression 
I  Expression  IFF  Expression 
1  Expression  IMPLIES  Expression 
1  Expression  OR  Expression 
I  Expression  AND  Expression 
I  NOT  Expression 
I  Expression  COMPOSE  Expression 
I  Expression  HIDING  BRA  NameListl  KET 
I  Expression  PROJECTION  Expression 
I  Expression  SUBST  Expression 

I  Expression  CROSS  {Expression  CROSS}  Expression 
I  PSET  Expression 
I  Prefix  Expression 
I  Expression  Postfix 
I  Expression  Infix  Expression 
I  Expression  Expression  {Expression} 

I  Expression  DECORATION 
I  Expression  SQBRA  RenameList  SQKET 
I  Expression  SELECT  NAME 
1  Expression  SELECT  NUMBER 
I  THETA  Expression 
I  Nofix 

I  NAME  SQBRA  ExpressionListl  SQKET 
I  SETBRA  ExpressionList  SETKET 
I  SETBRA  TextOrExpression  DOT  Expression  SETKET 
I  SETBRA  Text  SETKET 
I  BINDERBRA  BindList  BINDERKET 
I  BRA  Expression  COMMA  ExpressionListl  KET 
I  BRA  MU  TextOrExpression  KET 
1  BRA  Expression  KET 
1  STRING 
I  NUMBER 

I  SQBRA  Text  SQKET 

Again,  precedences  increase  as  we  go  down  the  page,  and  all  operators  are  left-associative  except  IMPLIES 
and  SUBST  which  are  right-associative. 

In  Standard  Z  schemas  are  expressions  and  expressions  are  schemas.  There  axe  two  advantages  to  this: 
•  in  proof,  it  upholds  the  substitutivity  of  equals  for  equals. 


Z  Notation  Version  1.1  SOth  June  1995 


129 


B  CONCRETE  SYNTAX  -  NORMATIVE  ANNEX 


•  in  specification,  it  allows  perfectly  sensible  idioms  which  are  currently  banned  (for  example,  if  I 
have  a  function  which  returns  sets  of  some  binding,  why  can’t  I  use  the  result  of  an  application 
of  the  function  in  a  normal  schema  expression?). 

We  can  decide  whether  something  should  be  evaluated  in  a  ‘declaration’  way  or  in  a  ‘set  of  bindings’ 
way  by  looking  at  where  it  occurs.  (We  presume  that  for  all  x,y  (eval-as-set-of-bindings  x)  =  (eval-as- 
set-of-bindings  y)  iff  (eval-as-declaration  x)  =  (eval-as-declaration  y)). 

Notice  that  now  we  can  decorate  an  arbitrary  expression  and  rename  an  arbitrary  expression  (although 
these  only  make  sense  in  type  terms  when  the  expression  involves  bindings). 

Notice  that  mu  expressions  with  no  dot  are  bracketed  because  the  schema  text  objects  inside  are  very 
low  precedence. 

Templates  use  an  extended  ‘grammar  for  operators’  similar  to  the  one  used  by  relations: 

Prefix  =  L  {Expression  ES  I  ExpressionList  SS} 

(Expression  ERE  |  ExpressionList  SRE) 

I  PRE 

Postfix  =  EL  {Expression  ES  I  ExpressionList  SS} 

(Expression  ER  |  ExpressionList  SR) 

I  POST 

Infix  =  EL  {Expression  ES  I  ExpressionList  SS} 

(Expression  ERE  I  ExpressionList  SRE) 

I  I 

Nofix  =  L  {Expression  ES  I  ExpressionList  SS} 

(Expression  ER  I  ExpressionList  SR) 

I  NAME 

The  template  application  is  similar  to  that  in  the  predicate  section,  but  here  we  obviously  don’t  have  the 
same  kind  of  chaining;  when  a  chain  of  templates  is  parsed  the  resulting  syntax  tree  must  be  rearranged 
to  a  form  consistent  with  the  precedence  and  associativity  figures  using  a  leftmost  derivation  using  an 
algorithm  such  as  [16].  Thus  if  we  have  a  juxtaposition  of  a  right  associative  operator  and  a  left 
associative  operator  _g-_  of  equal  precedence,  the  formula  x  p  y  q  z  parses  as  {x  p  y)  q  z. 

Note  that  the  precedences  defined  on  templates  only  work  with  respect  to  other  templates  -  other 
schemes  are  hard  to  process  for  user  and  machine. 

The  traditional  grammar  for  set  comprehensions  and  displays  has  an  ambiguity  -  the  distinction  of 
comprehensions  with  no  DOT  Expression  part  from  one-element  displays;  the  traditional  ‘solution’ 
would  be  to  put  brackets  in  like  this:  {(Expression)};  this  is  a  crime  against  brackets.  Our  proposal 
has  no  ambiguity,  and  relies  on  the  distinction  between  a  Schema  Text  and  a  Schema  Expression;  given 
any  Schema  Expression  S,  {S}  is  a  display  and  {Si true}  is  a  comprehension. 
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B.6.1  Schema  texts 
TextOrExpression  = 


Text 

1  Expression 

Text 

=  DeclPart  [VBAR  Predicate] 

DeclPaxt 

=  DeclElem  SEMICOLON  DeclElem  {SEMICOLON  DeclElem} 

1  BasicDecl 

DeclElem 

=  BasicDecl 

1  Expression 

BasicDecl 

=  NameListl  COLON  Expression 

There  is  no  explicit  abstract  syntax  for  schema  texts  but  it  is  important  to  still  have  things  which  look 
like  schema  texts  at  the  level  of  concrete  syntax. 

We  use  a  grammar  for  inline  schema  texts  which  can  have  any  schema  in  a  declaring  position.  Notice 
that  for  an  arbitrary  schema  expression  S  the  inline  schema  text  [S]  is  not  allowed  -  instead  the  user 
should  write  simply  S. 


B.6.2  Binding  and  renaming 

Bind  =  NAME  DEFINE_EQUAL  Expression 

Rename  =  NAME  RENAME  NAME 

There  should  be  no  surprises  here  -  this  is  exactly  the  same  as  the  traditional  Z  grammar. 

B.7  Lists 

ExpressionList  =  [ExpressionListl] 

ExpressionListl  =  Expression  {COMMA  Expression} 

NameList  =  [NeoneListl] 

NameListl  =  NAME  {COMMA  NAME} 

BindList  =  [BindListl] 

BindListl  =  Bind  {COMMA  Bind} 

RenameList  =  Rename  {COMMA  Rename} 


Z  Notation  Version  1.1  30th  June  1995 


131 


B  CONCRETE  SYNTAX  -  NORMATIVE  ANNEX 


B.8  Interface  to  the  lexical  analyzer 
B.8.1  Layout  rules 

Layout  information  is  used  in  traditional  Z  specifications 

•  to  replace  the  semicolons  in  the  declaration  parts  of  vertical  boxes. 

•  to  replace  the  conjunctions  in  the  predicate  parts  of  vertical  boxes. 

The  parser  relies  on  the  lexer  to  find  out  when  layout  information  is  being  used  and  to  insert  the 
appropriate  separators  (and  brackets  in  the  case  of  predicate  conjunctions)  into  the  token  stream  (the 
traditional  approach  to  dealing  with  layout  questions  is  to  resolve  them  at  the  lexical  analysis  stage  (cf 
Occam,  Haskell)). 


B.8. 2  Decorations,  words  and  names 

The  parser  relies  on  the  lexer  to  recognise  DECORATION  and  NAME.  Note  that  the  parser  has  no  idea 
whether  a  name  has  any  decorations  in  it;  there  is  no  notion  of  Word  in  the  abstract  syntax  (and  hence 
in  the  parser). 

Note  that  some  care  needs  to  be  shown  to  distinguish  between  the  decorated  expression 
(decorate  (name  "f") 
and  the  name 

(name  "f'") 

With  a  normal  treatment  of  whitespace,  the  string  would  parse  as  the  former  and  the  string  "f "" 

would  parse  as  the  latter. 
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B.9  Operator  definition  using  templates 
B.9.1  Prefix,  Postfix,  Infix,  Nofix 

A  token  /  corresponding  to  a  Word  in  traditional  Z  can  have  one  of  four  lexical  categories: 

Nofix  tokens  just  correspond  to  ordinary  Words. 

Prefix  tokens  must  be  followed  by  an  expression.  The  prefix  token  /  has  a  corresponding  nofix  token 
/-. 

Postfix  tokens  must  be  preceded  by  an  expression.  The  postfix  token  /  has  a  corresponding  nofix 
token  _/. 

Infix  tokens  must  be  followed  and  preceded  by  expressions.  The  infix  token  /  has  a  corresponding 
nofix  token 

Prefix,  postfix  and  infix  tokens  can  be  declared  by  declaring  the  corresponding  nofix  tokens  (though  nor¬ 
mally  only  at  top-level  in  support  tools  because  parsing  would  otherwise  require  typechecker  services). 
This  provides  a  simple  mechanism  for  coping  with  the  common  mathematical  operators,  allowing  the 
abstract  syntax  to  ignore  fixity  issues  by  simply  using  the  appropriate  nofix  tokens. 

We  can  define  a  grammar  for  this  kind  of  operator  definition: 

Fixity  =  LJ]  Word  LJ] 

(where  square  brackets  denote  an  optional  expression).  In  a  conventional  implementation  of  a  parser 
for  Z  fixity  definitions  will  pass  appropriate  token  information  to  the  lexical  analyser.  For  example,  the 
statement 

^  f 

would  define  /  as  a  postfix  token  and  _/  as  a  nofix  token.  The  parser  would  then  be  able  to  parse  a 
postfix  application 

X  f 

generating  the  abstract  syntax 

(functapp  (name  "_f”)  x) 

so  all  fixity  issues  are  a  matter  for  the  lexer  and  the  parser,  and  may  be  ignored  at  the  level  of  abstract 
syntax. 

But  this  regime  is  not  sufficiently  powerful  to  handle  even  basic  Z  toolkit  operators  such  as  relational 
image,  which  is  of  the  form  -/1-/2.  Traditionally,  specifiers  have  got  round  these  problems  by  defining 
combinations  of  tokens;  for  example,  -/1-/2  can  be  mimicked  by  defining  two  tokens  _/i_,  and  _/2;  this 
is  not  a  nice  solution  because  the  correspondence  with  a  single  nofix  token  is  lost  and  so  the  abstract 
syntax  contains  excess  structure. 
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B.9.2  Adding  structure  to  token  bodies 

To  get  round  this  problem  we  can  consider  adding  internal  structure  to  the  (ex-)  token  /  so  that  /  now 
corresponds  to  the  structure  fi  and  /2  are  a  pair  of  tokens  which  must  stand  either  side  of  an 

expression. 

The  new  operator  definition  syntax  is  then 
Fixity  =  C_]  Word  {_  Word}  [_] 

(where  curly  brackets  denote  zero  or  more  occurrences  of  an  expression).  We  could  then  define  a  token 
like  relational  image  thus: 

_  fl  _  f2 

which  would  define  fi  and  suitably,  and  _/i— as  a  nofix  token. 

So  how  can  fi  and  /2  be  suitably  defined,  such  that  we  can  generate  a  grammar  for  the  more  complex 
operator  applications? 

B.9.3  Parsing  structured  tokens 

Our  approach  is  to  define  an  additional  set  of  token  types.  As  well  as  INFIX,  PREFIX,  POSTFIX  and 
NAME  we  now  add 

L  tokens  at  the  start  of  a  ‘structured  token’  which  are  not  preceded  by  an  expression. 

EL  tokens  at  the  start  of  a  ‘structured  token’  which  are  preceded  by  an  expression. 

S  tokens  inside  a  ‘structured  token’. 

R  tokens  at  the  end  of  a  ‘structured  token’  which  are  not  followed  by  an  expression. 

RE  tokens  at  the  end  of  a  ‘structured  token’  which  are  followed  by  an  expression. 

and  provide  a  ‘grammar  for  operators’  thus: 

Prefix  =  L  {Expression  S>  Expression  RE 
1  PREFIX 

Postfix  =  EL  {Expression  S}  Expression  R 
I  POSTFIX 

Infix  =  EL  {Expression  S}  Expression  RE 
I  INFIX 

Nofix  =  L  {Expression  S}  Expression  R 
I  NAME 
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Some  section  of  the  Z  grammar  which  previously  looked  like  this: 


Expression  =  PREFIX  Expression 
I  Expression  POSTFIX 
I  Expression  INFIX  Expression 
I  NAME 


would  now  look  like  this: 


Expression  =  Prefix  Expression 
I  Expression  Postfix 
I  Expression  Infix  Expression 
I  Nofix 


This  gives  us  a  unified  mechanism  for  defining  operators  which  is  powerful  enough  to  define  the  basic 
forms  of  all  the  toolkit  operators.  In  order  to  handle  more  subtle  conditions  we  need  to  add  a  few 
complications  to  the  basic  scheme. 


B.IO  Generics 

In  Z  there  is  a  notion  of  infix  generics’.  For  example,  the  function  arrow  operator  is  a  function  which 
uses  its  arguments  as  generic  instantiations: 

X  ->  Y 

actually  equals 

(->[X,Y])(X,Y) 


We  could  add  another  kind  of  argument  slot,  #,  for  an  argument  which  is  used  as  a  generic  instantiation, 
so  that  we  could  write  the  template: 

#  ->  # 

This  has  the  advantage  that  we  can  also  say  things  like: 


add  _  to  # 

add  X  to  xs  =  (add_to_  [xs])(x,xs) 


where  the  above  operator  puts  items  into  sets. 


Z  Notation  Version  1.1  30th  June  1995 


135 


B  CONCRETE  SYNTAX  -  NORMATIVE  ANNEX 


B.ll  Precedence  and  associativity 

✓ 

In  order  to  resolve  ambiguities,  we  need  to  use  precedence  and  associativity  information.  The  ap¬ 
proach  adopted  in  the  standard  is  to  supply  one  numeric  precedence  value  and  a  choice  of  left  or  right 
associativity. 

B.11.1  Relations 

Relations  can  be  defined  using  the  same  kinds  of  mechanism  as  functions,  but  their  instances  are 
interpreted  as  set  membership  statements  rather  than  function  applications. 

To  provide  an  analogous  grammar  for  relational  operators,  we  use  the  same  scheme  as  for  functional 
operators,  with  minor  modifications. 

L  tokens  become  LP  tokens. 

EL  tokens  become  LP  tokens. 

S  tokens  stay  the  same. 

R  tokens  become  LP  tokens. 

RE  tokens  become  LP  tokens. 

and  the  grammar  for  operators  becomes: 

PrefixRel  =  LP  {Expression  S}  Expression  REP 
I  PREFIXREL 

PostfixRel  =  ELP  {Expression  S>  Expression  RP 
I  POSTFIXREL 

InfixRel  =  ELP  {Expression  S}  Expression  REP 
I  INFIXREL 

NofixRel  =  LP  {Expression  S}  Expression  RP 
The  basic  grammar  for  Relation  application  would  look  like  this: 


Relation  =  PrefixRel  Expression 
I  Expression  PostfixRel 
I  Expression  InfixRel  Expression 
I  NofixRel 

Most  versions  of  Z  allow  iterated  infix  relations: 
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Relation  =  PrefixRel  Expression 
I  Expression  PostfixRel 

I  Expression  InfixRel  Expression  {InfixRel  Expression} 
I  NofixRel 

We  could,  of  course,  go  further  down  this  road,  giving  us: 


Relation  =  ([PrefixRel]  Expression  {InfixRel  Expression}  [PostfixRel]) 

-  Expression 
I  NofixRel 

(where  ‘A  -  B’  denotes  subtraction  of  the  production  set  B  from  A)  but  popular  opinion  seems  to 
consider  this  a  step  too  far. 


B.ll. 2  Sequences 

When  an  expression  is  enclosed  on  both  sides  by  tokens,  we  have  an  opportunity;  we  could  also  permit 
a  comma-separated  list  of  expressions  to  occur  in  this  situation.  This  is  useful  in  defining  display 
operators. 

To  do  this,  we  provide  more  tokens: 

S  splits  into  ES  and  SS. 

R  splits  into  ER  and  SR. 

RE  splits  into  ERE  and  SRE. 

RP  splits  into  ERP  and  SRR 
REP  splits  into  EREP  and  SREP. 

The  prefixed  E  indicates  that  a  single  expression  is  expected  before  the  token;  while  the  prefixed  S 
indicates  that  a  sequence  of  expressions  (separated  by  commas)  is  expected  before  the  token. 

The  grammars  for  operators  change  in  the  obvious  way,  giving  us  the  final  scheme  which  is  used  in  the 
Z  Standard  syntax  definition. 

In  the  template  definition  syntax,  the  sequence  argument  slot  includes  a  triple  of  a  zero,  unit  injection, 
and  ‘union’  function,  which  are  used  at  parse-time  to  construct  the  appropriate  expression  from  the  list 
of  parsed  elements.  We  choose  the  triple  including  union  because  the  three  constituents  are  generally 
defined  for  most  generic  collections  anyway.  Here  is  how  one  might  go  about  defining  the  syntax  of  a 
sequence  display  operator  (where  the  constituents  of  the  triples  have  the  obvious  meanings). 

fixity  Iseq  ...  (emptyList ,incLkeSingletonSequence, concatenate)  rseq 

So  that 
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Iseq  x,y,z  rimg 
parses  as 

(functapp  (name  "Iseq.rseq") 

(functapp  (name  "concatenate") 

(functapp  (name  "concatenate") 

(functapp  (name  "makeSingletonSequence)  (name  "x")) 
(functapp  (name  "makeSingletonSequence)  (name  "y"))) 
(functapp  (name  "mzQceSingletonSequence)  (name  "z")))) 


and 


Iseq  rimg 
parses  as 

(functapp  (name  "Iseq.rseq")  (name  "emptyList") ) 


□ 
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Notes  on  this  section  of  the  Z  Standard 
Section  title:  Lexis 

Note:  Based  on  D«167  v2  and  D-177,  with  comments  from  syntax  sub¬ 
committee  meeting  18  May  1995;  also  comments  from  Meeting  27  of  the  Z 
Standards  Panel. 

Section  editor:  Susan  Stepney  (this  version  re-edited  by  JEN) 
Contributions  by:  Chris  Sennett,  Rob  Arthan,  Trevor  King,  . . .  (more  to 
be  added) 

Source  file:  lexis.tex 

Most  recent  update:  29th  June  1995 

Formatted:  3rd  July  1995 


Editor’s  note:  This  Annex,  though  it  has  been  revised,  has  not  yet  been  fully  updated  to  bring  it  into 
line  with  the  toolkit  Annex.  The  revision  will  be  completed  in  the  next  version.  JEN 


C.l  Introduction 

The  Concrete  Syntax  (Annex  B),  uses  named  tokens  to  define  its  terminal  symbols.  This  section 
defines  the  lexical  grammar  of  those  tokens  in  terms  of  Z  glyphs  (defined  in  section  C.4).  This  section 
describes  a  typical  rendering  of  the  tokens,  showing  how  they  might  be  displayed  on  a  printed  page 
or  a  graphics  screen.  The  detailed  appearance  of  the  tokens  is  device-dependent.  A  character-based, 
machine-representable  format,  and  the  Interchange  Format  representation  based  on  SGML  are  defined 
in  sections  C.4. 3  and  Annex  D. 


C.2  Soft  newlines 

Most  white  space  is  not  recognized  by  a  lexical  analyzer,  but  is  used  as  a  separator  when  recognis¬ 
ing  tokens.  In  two  special  contexts  some  white  space  (called  a  ‘hard  new  line’)  is  recognized:  as  a 
SEMICOLON  in  a  DeclPart,  as  a  CONJ  in  a  Pred,  The  rule  for  distinguishing  ‘soft’  (white  space)  and 
‘hard’  (recognised)  newlines  in  these  contexts  is  given  in  the  following  rules. 


1.  Tokens  that  can  appear  in  these  contexts  are  assigned  to  a  ‘soft  newline  category’,  based  on 
whether  the  token  could  start  or  end  a  declaration  or  predicate. 

•  BOTH:  new  lines  are  soft  before  and  after  the  token,  because  it  can  neither  start  nor  end  a 
declaration  or  predicate.  (It  is  ‘infix’,  for  example,  ‘:’) 

•  AFTER:  new  lines  are  soft  after  the  token,  because  it  cannot  end  a  declaration  or  predicate. 
(It  is  ‘prefix’,  for  example,  ‘[’) 
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•  BEFORE:  new  lines  are  soft  before  the  token,  because  it  cannot  start  a  declaration  or  pred¬ 
icate.  (It  is  ‘postfix’,  for  example,  ‘]’) 

•  NEITHER:  no  new  lines  are  soft,  because  such  a  token  could  start  or  end  a  declaration  or 
predicate.  (It  is  ‘nofix’,  for  example,  ‘^rue’) 

2.  When  a  new  line  appears  between  two  tokens  in  the  relevant  context,  the  newline  categories  of 
both  are  examined.  If  either  allows  the  newline  to  be  soft  in  that  position,  it  is  soft,  otherwise  it 
is  hard  (and  hence  recognised). 

3.  All  newlines  are  soft  outside  a  DeclPeirt  or  a  Pred.  So  tokens  that  cannot  appear  in  these  contexts 
can  be  considered  to  be  in  category  BOTH. 

The  Fixity  paragraph  allows  the  definition  of  various  mixfix  names,  which  are  placed  in  the  appropriate 
newline  category  (see  section  C.3.3).  Other  (ordinary)  user  declared  names  are  ‘nofix’,  and  so  are  placed 
in  NEITHER. 


C.3  Tokens 

ZToken  =  SIMPLE 
I  BOX 
I  MIXFIX 
I  DECORATION 
I  NAME 
NUMBER 


C,3.1  Simple  tokens 

SIMPLE  =  AND  I  ...  I  VBAR; 

A  typical  rendering  of  these  literal  tokens  is  given  below. 

The  third  column  defines  the  soft  newline  category  of  those  tokens  that  can  appear  in  the  context  of  a 
DeclPart  or  Pred.  The  fourth  column  notes  the  representation  syntax  productions  where  they  occur. 


Token  Representation 

AND  A 

BRA  ( 

COLON 

COMMA 

COMPOSE  ; 

CONJ  (newline) 

CROSS  X 

DEFINEEQUAL  == 

DOT  • 

EQUALS  = 


Newline 

Production 

BOTH 

Exp,  Pred 

AFTER 

Exp,  Pred,  SeqArg 

BOTH 

BasicDecl 

BOTH 

Exp,  SeqArg,  XListl 

BOTH 

Exp 

Pred 

BOTH 

Product 

BOTH 

Bind,  Paragraph 

BOTH 

Exp 

BOTH 

Relation 
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ELSE 

else 

BOTH 

Exp 

EXISTS 

3 

AFTER 

Exp,  Pred 

EXISTSl 

3i 

AFTER 

Exp,  Pred 

FALSE 

false 

NEITHER 

Pred 

FIXITY 

fixity 

Fixity 

FORALL 

V 

AFTER 

Exp,  Pred 

FREEBRA 

(( 

Branch 

FREEEQUALS 

FreeType 

FREEKET 

» 

Branch 

HIDING 

\ 

BOTH 

Exp 

IF 

if 

AFTER 

Exp 

IFF 

BOTH 

Exp,  Pred 

IMPLIES 

=» 

BOTH 

Exp,  Pred 

KET 

) 

BEFORE 

Exp,  Pred,  SeqArg 

LAMBDA 

A 

AFTER 

Exp 

LEFTFUN 

left  fun 

Category 

LET 

let 

Exp,  Pred 

MEMBER 

6 

BOTH 

Relation 

MU 

AFTER 

Exp 

NORMAL 

— 

Arg 

NOT 

“J 

AFTER 

Exp,  Pred 

OR 

V 

BOTH 

Exp,  Pred 

PRED 

pred 

AFTER 

Pred 

PRESCH 

pre 

AFTER 

Pred 

PROJECTION 

r 

BOTH 

Exp 

PSET 

p 

AFTER 

Exp 

REL 

rel 

Category 

RENAME 

BOTH 

Rename 

RIGHTFUN 

rightfun 

?? 

Category 

SEMICOLON 

j 

BOTH 

DeclElem,  DeclPart 

SEQUENCE 

SeqArg 

SELECT 

BOTH 

Exp 

SETBRA 

{ 

AFTER 

Exp 

SETKET 

} 

BEFORE 

Exp 

SQBRA 

[ 

AFTER 

Exp,  Formats,  Paragraph 

SQKET 

] 

BEFORE 

Exp,  Formats,  Paragraph 

THEN 

then 

BOTH 

Exp 

THETA 

e 

AFTER 

Exp 

TRUE 

true 

NEITHER 

Pred 

TURNSTILE 

h 

?? 

Paragraph 

TYPE 

$ 

?? 

Arg 

VBAR 

1 

BOTH 

Paragraph,  Text 
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C.3.2  Box  tokens 

BOX  =  AX  I  SCH  1  GEN  AFTER 
I  IS  I  ST  I  BAR  BOTH 
I  END  BEFORE 


A  typical  rendering  of  these  BOX  tokens  is  lines  drawn  around  the  Z  text. 
(Editor's  note:  add  three  examples.) 

The  Interchange  Format  (Annex  E)  defines  a  textual  form. 


C.3.3  Mixfix  token  categories 
MIXFIX  =  I  1  ...  I  SREP 

For  the  base  language,  these  token  categories  are  empty.  They  are  populated  by  definitions  using  the 
template  structure  of  the  fixity  paragraph,  such  as  toolkit  definitions. 

The  second  column  defines  the  soft  newline  category  of  names  declared  in  these  token  categories.  The 
third  column  notes  the  representation  syntax  productions  where  these  tokens  occur. 


Token 

Newline 

I,  IP 

BOTH 

POST,  POSTP 

BEFORE 

PRE,  PREP 

AFTER 

EL,  ELP 

BOTH 

ER,  ERP 

BEFORE 

ERE,  EREP 

BOTH 

ES 

BOTH 

L,  LP 

AFTER 

SR,  SRP 

BEFORE 

SS 

BOTH 

SRE,  SREP 

BOTH 

Production 

Infix 

Postfix 

Prefix 

Postfix,  Infix 
Postfix,  Nofix 
Prefix,  Infix 

Prefix,  Postfix,  Infix,  Nofix 
Prefix,  Nofix 
Postfix,  Nofix 
Prefix,  Postfix  Infix 
Prefix,  Infix 


C.3.4  Decoration,  name  and  number  tokens 

DECORATION  =  STROKE,  {STROKE}; 

NAME  =  WORD,  {STROKE}; 

NUMBER  =  ‘0’  I  DIGITl,  {DIGIT}; 


All  these  tokens  are  in  the  soft  newline  category  NEITHER. 

Notice  that  the  lexis  allows  a  NAME  to  include  STROKES,  and  that  the  concrete  syntax  allows  an  expression 
to  be  decorated  with  STROKES.  When  the  expression  is  a  NAME,  the  two  cases  are  disambiguated  by 
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white  space:  x\  is  the  undecorated  NAME  consisting  of  the  WORD  'x'  followed  by  the  STROKE  x !  is 
the  decorated  expression  consisting  of  the  NAME  ‘i’  decorated  with  the  STROKE  *!’;  a;! !  is  the  decorated 
expression  consisting  of  the  WORD  ‘x!’  decorated  with  the  STROKE  *!’. 

STROKE  =  I  *!’  I  “?’  I  SUBSCRIPT; 

SUBSCRIPT  =  DOWN,  GLYPH,  {DOWN,  GLYPH}, UP 


The  DOWN  and  UP  subscript  delimiter  tokens  could  be  presented  as  in-line  literals,  or  they  could  indicate 
a  lowering/raising  of  the  text,  and  possible  size  change.  Such  rendering  details  are  not  defined  here. 

ALPHASTRING  =  {LETTER  |  DIGIT} 

SYMBOLSTRING  =  {SYMBOL} 

WORDPART  =  ‘  J,  (ALPHASTRING  |  SYMBOLSTRING) 

WORD  =  WORDPART,  {WORDPART} 

I  LETTER,  ALPHASTRING,  WORDPART 
1  SYMBOL,  SYMBOLSTRING,  {WORDPART} 

C.4  Glyphs 

GLYPH  =  DIGIT  |  LETTER  |  SYMBOL  |  SPECIAL 

The  glyph  sets  forming  GLYPH  are  disjoint.  SYMBOL  is  a  user-extensible  glyph  set  for  making  new  symbolic 
identifiers:  this  is  where  characters  from  other  alphabets  (such  as  Japanese  or  Russian)  can  be  added. 

DIGITl  =  T’  I  ‘2’  I  ‘3’  I  ‘4’  |  ‘5’  |  ‘6’  |  7’  |  ‘8’  1  ‘9’; 


DIGIT 


=  ‘0’  I  DIGITl; 


LETTER  =  ‘o’  I  ‘6’  I  ‘c’  |  ‘d’  |  ‘e’  |  ‘/’  |  ‘j’  |  ‘h’  |  ‘j’  |  ‘j’  |  ‘jfc’  |  ‘Z’  |  ‘m’ 

I  ‘n’  I  ‘o’  I  ‘p’  I  ‘q'  I  ‘r’  |  ‘s’  |  ‘f’  |  ‘u’  |  ‘u’  |  ‘w’  |  ‘a:’  |  ‘p’  |  ‘z' 

1  ‘d’  I  ‘S’  I  ‘(7’  I  ‘S’  I  ‘S’  I  ‘S’  I  ‘S’  I  ‘S’’  I  ‘S  I  ‘J’  I  ‘S’  I  ‘L’  I  ‘M’ 

1  ‘iV’  I  ‘O’  I  ‘S’  I  ‘Q’  I  ‘S’  I  ‘5’  I ‘T’  j  ‘S’  I  ‘F’  I  ‘IS’  I  ‘Jf’  I  ‘F’  I  ‘S’ 
j  ‘T’  I  ‘A’  I  ‘0’  I  ‘A’  I  ‘5’  I  ‘R’  I  ‘S’  I ‘T’  I  ‘$’  I  ‘-J-’  I  ‘S’ 

I  ‘a’  I  ‘f3'  I  Y  I  ‘<5’  I  ‘e’  I  ‘C’  I  V  I  ‘0’  I  ‘t’  I'k’  I  ‘A’  I  ‘p’ 

I  I  ‘C  I  ‘tt’  I  ‘p’  I  ‘<t’  I  ‘r’  I  V  I  ‘</)’  I  ‘x’  I  ‘V>’  I  ‘co’ 


SYMBOL  =  '$’  I  ’  I  ‘.’  I  ‘/’  I  ‘  :  ’  T;  ’  r  =  ’  I  ‘[’  I  ‘]’  I  ‘{’  I  ‘  I  ’  I  ‘}’ 
|‘A’|‘ V’|‘-.’|‘=^^’|‘<=>’|‘V’|‘3’ 


|‘x’|‘P’|‘.’|‘((’l‘))’|‘h’ 

l‘  ?’l‘r  |‘V 

I  any  toolkit  glyphs,  including  MIXFIX  (as  supported) 
I  any  user  glyphs,  including  MIXFIX 


SPECIAL  =  BOX 

I  ‘'’  I  ‘!’  I  ‘?’ 

I  ‘(’  1  ')’  I 
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C.4.1  Examples 

A  glyph  in  the  LETTER  or  DIGIT  class  may  be  rendered  differently  for  reasons  of  emphasis  or  aesthetics, 
but  it  still  represents  the  same  glyph.  For  example,  ‘d’,  ‘d’,  ‘d’  and  ‘d’  are  all  the  same  glyph.  This 
explains  why  those  Greek  characters  that  are  identical  in  appearance  to  Roman  characters  do  not  appear 
twice  in  the  list  of  letters. 

A  glyph  in  the  SYMBOL  class,  which  includes  user-defined  glyphs,  must  appear  the  same  wherever  it  occurs 
in  a  specification.  For  example,  schema  composition  9  and  the  toolkit  glyph  relational  composition  ? 
are  different  glyphs. 

Once  a  NAME  has  been  recognised,  if  it  consists  of  the  glyph  string  corresponding  to  a  SIMPLE  token, 
it  is  recognised  as  that  token  instead.  For  example,  P  is  recognised  as  PSET,  but  P^  (‘P’,  DOWN,  ‘1’, 
UP)  and  P45  (‘P’,  DOWN,  UP,  DOWN,  ‘5’,  UP)  are  recognised  as  NAMEs.  For  example,  3^  (‘3’,  DOWN,  ‘1’, 
UP)  is  recognised  as  EXISTSl,  but  3o  (‘3’,  DOWN,  'O’,  UP)  is  recognised  as  a  NAME. 

Underscore,  is  used  in  words  to  separate  strings  of  alphanumerics  from  strings  of  symbols.  For 
example,  ‘r_oo_2/’  is  a  single  word,  whereas  'r  ooy’  consists  of  the  three  words  'r’,  ‘00’  and  ‘y’.  For 
example,  T_Jf’  is  a  single  word,  whereas  ‘PA’  is  the  token  PSET  followed  by  the  word  ‘A’. 

(Editor's  note;  more  examples  here?) 


C.4.2  Glyph  representations 

We  present  the  glyphs  of  the  Base  language  in  a  variety  of  formats,  designed  for  different  purposes. 

Spoken  name  A  suggested  form  for  reading  the  glyph  out  loud,  designed  for  use  in  reviews,  or  for 
discussing  specifications  over  the  telephone.  (An  English  language  form  only  is  given;  other  natural 
languages  may  well  use  other  forms.) 

Interchange  The  format  for  use  with  the  SGML  interchange  format  (chapter  ????) 

Email  The  format  for  rendering  the  glyph  on  a  low  resolution  device,  such  as  a  character-based  ter¬ 
minal,  or  e-mail  conversation.  (The  email  form  for  digits  and  the  Roman  alphabet  is  the  obvious 
one,  and  is  not  given  explitily.) 

The  character  7,  is  used  to  flag  a  special  string,  for  example  x  as  7oX,  and  disambiguate  it  from,  for 
example  the  name  x,  to  ease  machine  processing.  This  flag  character  may  be  omitted  to  reduce 
clutter,  if  there  is  no  intention  to  machine- process  the  text. 

Mathematical  The  format  for  rendering  the  glyph  on  a  high  resolution  device,  such  as  a  bit-mapped 
screen,  or  on  paper  (either  hand- written,  or  printed). 

Other  formats  may  be  used  for  other  purposes,  as  required. 

Toolkit  glyphs  are  described  in  the  toolkit  chapter. 
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C.4.3  Base  language  glyphs 


Spoken  name 

Interchange 

Email 

Mathematical 

and 

&:and 

/\ 

A 

left  [parenthesis] 

( 

( 

( 

colon 

: 

comma 

schema  compose 

j 

&scomp 

k; 

) 

o 

9 

cross 

&times 

lx 

X 

define  equal 

== 

== 

=zz= 

fat  dot  1  spot 

febull 

• 

equals 

= 

= 

z:z 

else 

else 

else 

else 

exists 

fcexist 

IE 

3 

unique  exists 

&:existl 

y«Ei 

3i 

false 

false 

false 

false 

fixity 

fixity 

fixity 

fixity 

for  all 

&forall 

Ik 

V 

left  chevron  [bracket] 

felchev 

« 

« 

free  equals 

;  :  = 

right  chevron  [bracket] 

ferchev 

» 

>> 

hide 

&hide 

•/o\ 

\ 

if 

if 

if 

if 

equivalent  |  if  and  only  if 

feiff 

<=> 

implies 

&rArr 

right  [parenthesis] 

) 

) 

) 

left  function 

leftfun 

leftfun 

leftfun 

let 

let 

let 

let 

member  |  in 

feisin 

%e 

€ 

not 

&:not 

” } 

“n 

argument 

__ 

or 

&:or 

\/ 

V 

coerce  predicate 

&:pred 

pred 

pred 

pre  [condition] 

&:pre 

pre 

pre 

project 

&proj 

y.i\ 

r 

power  [set] 

&pset 

y.p 

p 

relation 

rel 

rel 

rel 

rename 

/ 

/ 

/ 

right  function 

rightfun 

rightfun 

rightfun 

semi[colon] 

> 

1 

sequence  argument 

.  .  . 

select  1  dot 

left  set  [bracket] 

&:lcub 

{ 

right  set  [bracket] 

&:rcub 

} 

} 

left  square  [bracket] 

&lsqb 

c 

[ 

right  square  [bracket] 

&rsqb 

] 

] 
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then 

then 

then 

then 

true 

true 

true 

true 

turnstile 

&;vdash 

1- 

1- 

type  argument 

&num 

$ 

$ 

bar 

&;verbar 

1 

1 

C.4.4  Greek  alphabet  glyphs 


Spoken  name 

Interchange 

Email 

Mathematical 

alpha 

&alpha 

'/.alpha 

a 

beta 

&beta 

Xbeta 

gamma 

&gamma 

'/.gamma 

7 

delta 

&delta 

y.delta 

5 

epsilon 

&:epsi 

^epsilon 

€ 

zeta 

&zeta 

y.zeta 

c 

eta 

&;eta 

'/let  a 

V 

theta 

&:thetas 

/Itheta 

e 

iota 

&iota 

/liota 

L 

kappa 

fekappa 

'/.kappa 

K 

lambda 

&lambda 

/.lambda 

X 

mu 

&:mu 

'/jnu 

ft 

nu 

&:nu 

'/.nu 

V 

xi 

&xi 

'/.xi 

e 

pi 

&pi 

'/.pi 

7r 

rho 

&rho 

'/.rho 

P 

sigma 

&;sigma 

'/.sigma 

a 

tau 

&tau 

/tau 

T 

upsilon 

&upsi 

%upsilon 

V 

phi 

fephis 

7.phi 

<l> 

chi 

fechi 

'/.chi 

X 

psi 

&psi 

'/.psi 

■4) 

omega 

&omega 

'/.omega 

w 

big  delta 

feDelta 

y, Delta 

A 

big  gamma 

&  Gamma 

y.Gamma 

r 

big  theta 

&Theta 

y.Theta 

0 

big  lambda 

&:Lambda 

'/.Lambda 

A 

big  xi 

&Xi 

'/.Xi 

big  pi 

&Pi 

'/.Pi 

n 

big  sigma 

feSigma 

'/.Sigma 

s 

big  upsilon 

&:Upsi 

yUpsilon 

T 

big  phi 

&Phi 

'/.Phi 

big  psi 

&Psi 

'/.Psi 

big  omega 

&Omega 

'/.Omega 

n 
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C.5  Toolkit  glyphs 

Glyph  representations  axe  provided  for  the  new  glyphs  introduced  in  the  Toolkit. 

Editor’s  note:  The  precise  contents  of  this  list  depends  on  the  chosen  Tookit,  and  hence  is  subject  to 
change. 


Spoken  name 

Interchange 

Email 

Mathematical 

not  equal 

&ne 

/= 

non  in 

&notin 

7,/e 

empty  [set] 

&empty 

(/) 

0 

subset 

&sube 

7.c_ 

c 

not  subset 

&nsube 

7./c_ 

g 

proper  subset 

&sub 

7,c 

c 

not  proper  subset 

&nsub 

7./C 

[set]  union 

&:cup 

7.U 

u 

[set]  intersection 

&cap 

7.n 

n 

set  difference 

fesdiff 

\ 

\ 

set  symmetric  difference 

&:ssdiff 

W 

\\ 

generalised  union 

(feBigcup 

7.11U 

U 

generalised  intersection 

feBigcap 

7.nn 

n 

finite  sets 

&fset 

y.F 

F 

relation 

&;rel 

<— > 

4-4- 

maplet 

&:map 

1— > 

l-l- 

[relational]  compose 

&:rcomp 

•/.; 

o 

9 

functional  compose 

&compfn 

7.0 

0 

domain  restrict 

&:dres 

<: 

<3 

range  restrict 

fcrres 

:> 

> 

domain  subtract 

fcdsub 

<-: 

< 

range  subtract 

&rsub 

> 

inverse 

&tilde 

left  relational  image  bracket 

&limg 

(1 

d 

right  relational  image  bracket 

&rimg 

1) 

1) 

transitive  closure  |  plus 

&:tcl 

1  + 

+ 

refiexive  transitive  closure  |  star 

&:rtcl 

1* 

♦ 

[relational]  override 

&oplus 

(+) 

0 

[partial]  function 

&pfun 

-|-> 

-H- 

total  function 

&rarr 

— > 

[partial]  injection 

&;pinj 

>-!-> 

)-f-> 

total  injection 

&rarrtl 

>— > 

)— > 
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[partial]  surjection 

&psur 

-i-» 

total  surjection 

&Rarr 

— » 

bijection 

febij 

> — » 

finite  function 

&:fpfun 

-ii-> 

finite  injection 

&fpinj 

nat[ural  number] 

&nat 

•/.N 

N 

integer 

feint 

•/.z 

Z 

rational 

ferat 

*/.Q 

Q 

real  [number] 

fereal 

y.R 

M 

less  than 

felt 

< 

< 

less  than  or  equal  to 

fele 

<= 

< 

greater  than 

fegt 

> 

> 

greater  than  or  equal  to 

fege 

>= 

> 

up  to 

fenldr 

. . 

plus 

+ 

+ 

+ 

[unary]  minus 

feuminus 

- 

[binary]  minus 

febminus 

- 

- 

times 

♦ 

* 

* 

cardinality  |  hash 

fenum 

# 

# 

[real]  divide 

fedivide 

•/./ 

div 

left  seq[uence  bracket] 

felang 

•/.< 

( 

right  seq[uence  bracket] 

ferang 

•/•> 

> 

filter 

fefilter 

l\ 

r 

co-filter 

fecofilter 

1/ 

L 

extract 

feextract 

/I 

1 

co-extract 

fecoextract 

\l 

concatenate 

fefrown 

left  bag  [bracket] 

felbag 

[i 

I 

right  bag  [bracket] 

ferbag 

|] 

1 

□ 
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Notes  on  this  section  of  the  Z  Standard 

Section  title:  Mathematical  toolkit 
Section  editor:  John  Wordsworth 

Contributions  by:  John  Wordsworth,  ...  (others  to  he  added) 

Source  file:  tooIkit.tex 

Most  recent  update:  30th  June  1995 

Formatted:  3rd  July  1995 


Editor’s  note:  In  this  version,  the  only  major  change  to  this  Annex  has  been  the  addition  of  fixity 
definitions  to  some  of  the  definitions. 


Introduction 

This  section  defines  a  Mathematical  Toolkit  or  Library  for  use  with  the  Z  notation.  The  principle  is 
that  those  constructions  that  can  be  defined  in  terms  of  others  are  included  in  the  Toolkit  rather  than 
in  the  core  notation — this  simplifies  the  core  notation. 

Most  users  will  want  to  make  use  of  the  constructions  defined  in  this  section.  This  can  therefore  be 
regarded  as  a  basic  Toolkit,  which  users  may  augment  with  their  own  definitions,  or  replace  if  these 
definitions  are  not  suitable  for  their  use. 

In  this  version  of  the  Z  Standard,  the  list  of  defined  items  follows  the  customary  list  of  Toolkit  items. 
Later  versions  of  the  Standard  may  include  further  definitions  and  explanations,  and  will  link  the  Toolkit 
to  related  work  on  the  semantics  and  proof  system  for  Z. 

Definitions  of  the  Mathematical  Toolkit  are  informally  explained  and  illustrated.  In  some  cases  an 
illustration  for  one  part  of  the  Toolkit  may  rely  on  terms  defined  earlier  in  the  toolkit.  Many  of  the 
definitions  given  here  are  generic  with  respect  to  one  or  more  sets. 


Editor’s  note:  The  following  note  appeared  an  an  earlier  version.  It  is  retained  for  possible  use. 

Instantiation  of  a  generic  definition  can  be  performed  with  any  appropriate  sets,  not  necessarily 
the  maximal  sets  of  their  types.  However  the  informal  descriptions  of  these  definitions  are  often 
here  expressed  as  if  the  sets  used  for  instantiation  were  in  fact  types,  since  that  is  the  way  in 
which  these  definitions  are  commonly  instantiated  in  Z  specifications. 

Reviewers  of  the  draft  standard  are  invited  to  comment  on  this  approach. 
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D.l  Sets 
Name 

—  Inequality 
^  Non-membership 

Definition 

fixity  rel  _  7^  _ 
fixity  rel  _  ^  _ 

F=[X] 

X  wPX 

'i  X,  y  :  X  •  X  ^  y  ^  -I  {x  =  y) 
y  X  :  X;  S  :F  X  •  X  ^  S  4^  ^  {x  &  S) 


Description 

Inequality  is  a  relation  between  values  of  the  same  type.  The  predicate  x  ^  y  denotes  true  when  x  =  y 
denotes  false. 

Non-membership  is  a  relation  between  values  of  a  certain  type  and  sets  of  values  of  that  type.  The 
predicate  x  ^  S  denotes  true  when  x  G.  S  denotes  false. 
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Name 


0  -  Empty  Set 

C  —  Subset  relation 
C  —  Proper  subset  relation 
Pj  —  Non-empty  subsets 

Definition 

0[X]  =={x:X|/aZ5e} 

fixity  rel  -  C  _ 
fixity  rel  _  C  _ 

F=[^] . . 

-C_,_C-:'PX 

\/S,T:¥X* 

iSCT<^{Vx:X»xeS=^xeT))A 

ScT^SCTaS^T) 


r^x  =={s  :rx\sjt0} 


Description 

The  empty  set  of  values  of  a  certain  type  is  the  set  of  values  of  that  type  that  has  no  members. 

If  S  and  T  are  sets  of  values  of  the  same  type,  then  5  C  T  is  a  predicate  denoting  true  if  and  only  if 
every  member  of  5  is  a  member  of  T.  The  empty  set  of  values  of  a  certain  type  is  a  subset  of  every  set 
of  values  of  that  type. 

If  S  and  T  are  sets  of  values  of  the  same  type,  then  5  C  T  is  a  predicate  denoting  true  if  and  only  if 
every  member  of  5  is  a  member  of  T  and  S  and  T  are  not  equal.  If  5  is  a  proper  subset  of  T,  then  it 
is  also  a  subset  of  T.  The  empty  set  of  values  of  a  certain  type  is  a  proper  subset  of  every  non-empty 
set  of  values  of  that  type. 

If  X  is  a  set,  then  X  is  the  set  of  all  non-empty  subsets  of  X.  P^  X  is  a  proper  subset  of  PX. 
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Name 

U  —  Set  union 
D  —  Set  intersection 
\  —  Set  difference 

Definition 

fixity  leftfun  0  -U_ 
fixity  leftfun  0  _n_ 
fixity  leftfun  0  _  \  _ 


ri^] 

xFx^rx 

V5,  riPx* 

5'ur  =  {x:X|are5Va:G  T}A 
5nr  =  {a::A’|a;eiS'Aa;eT}V 
S\  T  =  {x:X\xeS  Ax^  T} 


Description 

The  union  of  two  sets  of  values  of  the  same  type  is  the  set  of  values  that  axe  members  of  either  set. 

The  intersection  of  two  sets  of  values  of  the  same  type  is  the  set  of  values  that  are  members  of  both 
sets. 

The  difference  of  two  sets  of  values  of  the  same  types  is  the  set  of  values  that  are  members  of  the  first 
set  but  not  members  of  the  second. 
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D.l  Sets 


Name 

U  —  Generalized  union 
D  —  Generalized  intersection 

Definition 

rW 

U,n:P(PZ)— >PX 
V^:P(PA’)* 

UA  =  {x  :  X  \  {3S  :  A  •  X  €  S)}  /\ 
nyl  =  {a::Z|(V5:>l.a:G5)} 


Description 

The  generalised  union  of  a  set  of  sets  of  values  of  the  same  type  is  the  set  of  values  of  that  type  that 
are  members  of  at  least  one  of  the  sets. 

The  generalised  intersection  of  a  set  of  sets  of  values  of  the  same  type  is  the  set  of  values  of  that  type 
that  are  members  of  every  one  of  the  sets. 
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Name 

first,  second  —  Projection  functions  for  ordered  pairs 


Definition 

MX,  Y] 

first:XxY-^X 
second  :  X  x  Y  — >  Y 

^x:X\y:Y  • 

first{x,  y)  =  X  A 
second{xj  y)  ^  y 


Description 

For  any  ordered  pair  (a;,  y),  first{Xy  y)  is  x  and  second{x^  y)  is  y. 
If  p  is  of  type  X  x  Y ^  then  p  =  {first  p,  second  p). 
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D.2  Relations 
Name 

^  —  Binary  relations 
^  “  Maplet 

Definition 

fixity  leftfun  0 
fixity  leftfun  0  _  _ 

X  y  ==  F{X  X  Y 


=[z,  r]- . — . 

X  X  Y 

yx-.X-,y:Y» 
x*-^y  =  {x,y) 


Description 

X  y  is  the  set  of  all  sets  of  ordered  pairs  whose  first  members  are  members  of  X  and  whose  second 
members  are  members  of  Y.  To  declare  i? :  X  ^  y  is  to  say  that  R  is  such  a  set  of  ordered  pairs. 

The  maplet  forms  an  ordered  pair  from  two  values,  so  if  x  is  of  type  X  and  y  is  of  type  y,  then  x  y 
is  of  type  X  x  y.  3:  y  is  thus  just  another  notation  for  (a;,  y). 
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Name 

dom,  ran  —  Domain  and  range  of  a  relation 


Definition 


Description 

The  domain  of  a  relation  R  is  the  set  of  first  members  of  the  ordered  pairs  in  R.  If  R  is  of  type  X  F , 
the  domain  of  R  is  of  type  PX.  If  iZ  is  an  empty  relation,  then  its  domain  is  an  empty  set. 

The  range  of  a  relation  R  is  the  set  of  second  members  of  the  ordered  pairs  in  R.  If  R  is  of  type  X  F, 

the  domain  of  R  is  of  type  P  F.  If  iZ  is  an  empty  relation,  then  its  range  is  an  empty  set. 
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Name 

id  —  Identity  relation 

;  —  Relational  composition 

o  —  Backward  relational  composition 


Definition 

id  X  ==  {x:X9x^x} 

fixity  leftfun  0  _ ;  _ 
fixity  leftfun  0  _o_ 

F=[^,  Y,X]-- . 

{X  Y)  X  {Y  ^  Z)  ^  {X  ^  Z) 

_o_  :  (Y^Z)  xiX^Y)-^  lx^Z) 

y  R  :  X  Y]  S  :  Y  ^  Z  • 

R°,S  =  SoR  =  {x:X-,y:Y-,z:Z\ 

{xi-^y)€RA{y>-^z)£S»x>-^z} 


Description 

The  identity  relation  on  a  set  X  is  the  relation  that  relates  every  member  of  X  to  itself.  Its  type  is 
X  ^  X .  The  identity  relation  on  an  empty  set  is  an  empty  relation. 

The  relational  composition  of  a  relation  R  :  X  ^  Y  and  5  :  Y  <r^  Z  is  a,  relation  of  type  X  Z 
formed  by  taking  all  the  pairs  {x,y)  of  R  whose  second  members  are  in  the  domain  of  5,  and  relating 
X  to  every  member  of  Z  that  y  is  related  to  by  5. 

The  backward  composition  of  S  and  R  is  the  same  as  the  composition  of  R  and  S. 
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Name 

<  —  Domain  restriction 
>  -  Range  restriction 


Definition 

fixity  leftfun  0  _  <  _ 
fixity  leftfun  0  _  >  _ 


Description 

The  domain  restriction  of  a  relation  i?  :  X  T  by  a  set  5  :  P  is  the  set  of  pairs  in  R  whose  first 

members  axe  in  S.  S  <  R  is  n  subset  of  i?,  and  its  domain  is  a  subset  of  S, 

The  range  restriction  of  a  relation  R  :  X  Y  by  a,  set  T  :¥  Y  is  the  set  of  pairs  in  R  whose  second 

members  are  in  T,  R>  T  is  a  subset  of  i?,  and  its  range  is  a  subset  of  T. 
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Name 

<  —  Domain  anti-restriction 
^  -  Range  anti-restriction 


Definition 

fixity  leftfun  0  _  _ 

fixity  leftfun  0  _  >  _ 


Description 

The  domain  anti-restriction  of  a  relation  R  :  X  <->  7  by  a  set  5  :  P  Z  is  the  set  of  pairs  in  R  whose 
first  members  are  not  in  S'.  5  <  iZ  is  a  subset  of  R,  and  its  domain  contains  no  members  of  S'. 

The  range  anti-restriction  of  a  relation  iZ  :  X  7  by  a  set  T  :  P  7  is  the  set  of  pairs  in  R  whose 
second  members  are  not  in  T.  iZ  >  T  is  a  subset  of  iZ,  and  its  range  contains  no  members  of  T, 
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Name 

—  relational  inversion 


Definition 

fixity  leftfun  0 


MX,  n  . 

:  {X  Y)  ^  (Y  X) 

'iR:X^Y» 

R"  =  {x  :  X-,  y: 


Description 

The  inverse  of  a  relation  is  the  relation  obtained  by  reversing  every  ordered  peiir  in  the  relation. 
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D.2  Relations 


Name 

->(!_[)  —  Relational  image 


Definition 

fixity  leftfun  0  _(|_D 


[=[^,  Y]  . . 

44  :{X  ^Y)xFX  ^FY 


^R:X^Y]S:FX^ 

i?(|<?[)  —  {x  :  X]  y  :  Y\xES  A  {xi-^y)ER9yy 


Description 

The  relational  image  of  a  set  5  :  P  X  under  a  relation  iZ  :  X  ^  7  is  the  set  of  values  of  type  Y  that 
are  related  under  iZ  to  a  value  in  S. 
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Name 

_+  _  Transitive  closure 

—  Reflexive-transitive  closure 


Definition 

fixity  leftfun  0  _"*■-. 
fixity  leftfun  0 


:  {X  X)  ^  {X  X) 
yR:X^X  • 

R+  =  n{Q  :  X  X  \  R  C  Q  A  Q  Q  C  Q}  A 

R*  =  n{Q:X<^X\idXCQARCQAQ’,QCQ} 


Description 

The  transitive  closure  of  a  relation  R  :  X  X  is  the  relation  obtained  by  relating  each  member  of 
the  domain  of  R  to  its  images  under  R,  and  to  anything  related  to  any  of  its  images  under  R  by  any 
number  of  steps  of  apphcation  of  R. 

The  reflexive  transitive  closure  of  a  relation  R  :  X  is  the  relation  formed  by  extending  the  transitive 
closure  of  R  by  the  identity  relation  on  X. 


162 


Z  Notation  Version  1.1  30th  June  1995 


D,3  Functions 


D.3  Functions 
Name 


-H-  —  Partial  functions 


—  Total  functions 


Definition 

fixity  leftfun  0 
fixity  leftfun  0  — > 

{f:X^Y\{yx:X-,yuy2:Y. 

(a:  1-4  j/i)  €  /  A  (a;  ^2)  €  /  j/i  =  j/2)  } 

Z  — )■  y  ==  {/  :  Z  44  y  I  dom/  =  X  } 


Description 

The  partial  functions  from  Z  to  y  are  a  subset  of  the  relations  Z  y.  They  are  distinguished  by  the 
property  that  each  a;  in  X  is  related  to  at  most  one  y  in  Y.  X  -)->•  y  is  the  set  of  all  partial  functions 
from  X  to  y,  and  to  declare  /:  X  -14  y  is  to  say  that  /  is  one  such  partial  function. 

The  total  functions  from  X  to  y  are  a  subset  of  the  partial  functions  X  4->  y.  They  are  distinguished 
by  the  property  that  each  a;  in  X  is  related  to  exactly  one  y  in  Y.  X  — )•  y  is  the  set  of  all  total 
functions  from  X  to  y,  and  to  declare  /:  X  -4  y  is  to  say  that  /  is  one  such  total  function.  The 
domain  of  /  :  X  — >  Y  is  X. 
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Name 

—  Partial  injections 
>— >  —  Total  injections 


Definition 

fixity  leftfun  0 
fixity  leftfun  0 

y  == 

{f  :  X  -H'  Y  \{Vxi,X2:  domf  •  f{xi)  =  f{x2)  =^xi=X2)} 

X  w  y  ==  (x  y)  n  (X  — >  y) 


Description 

The  partial  injections  from  X  to  T  are  a  subset  of  the  partial  functions  X-^Y.  They  are  distinguished 
by  the  property  that  each  y  in  y  is  related  to  at  most  one  r  in  X.  Thus  the  inverse  of  a  partial  injection  is 
also  a  partial  injection.  X  Y  is  the  set  of  all  partial  injections  from  X  to  y ,  and  to  declare  f  :  Xyn^Y 
is  to  say  that  /  is  one  such  partial  injection. 

The  total  injections  from  X  to  y  are  a  subset  of  the  partial  injections  X  y .  They  are  distinguished 
by  the  property  that  each  r  in  X  is  related  to  exactly  one  y  in  y.  X  y  is  the  set  of  all  total 
injections  from  X  to  y,  and  to  declare  /  :  X  y  is  to  say  that  /  is  one  such  total  injection. 
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Name 

-+^  —  Partial  surjections 
—*  —  Total  surjections 
>-»  —  Bijections 


Definition 

fixity  leftfun  0  -t-» 
fixity  leftfun  0  — » 
fixity  leftfun  0  >-^ 

X-H^Y=={f:X-+^  y  iran/=  Y} 
X  ^  Y  ==  {X  Y)  n{X  Y) 
Xy^Y===  {X-^Y)n  {X  y^Y) 


Description 

The  partial  surjections  from  X  to  T  are  a  subset  of  the  partial  functions  X-+^Y.  They  are  distinguished 
by  the  property  that  each  y  in  Y  is  related  to  at  least  one  or  in  X.  X  -i^  Y  is  the  set  of  all  partial 
surjections  from  X  to  Y,  and  to  declare  /  :  X  Y  is  to  say  that  /  is  one  such  partial  surjection. 

The  total  surjections  from  X  to  Y  are  a  subset  of  the  partial  surjections  X-^Y.  They  are  distinguished 
by  the  property  that  each  x  in  X  is  related  to  exactly  one  y  in  Y.  A"  Y  is  the  set  of  all  total  surjections 
from  X  to  Y,  and  to  declare  /  :  A  Y  is  to  say  that  /  is  one  such  total  surjection. 

The  bijections  from  A  to  Y  are  a  subset  of  the  total  surjections  A  — »■  Y.  They  are  distinguished  by 
the  property  that  each  «/  in  Y  is  related  to  exactly  one  x  in  A.  X  y-*  Y  is  the  set  of  all  bijections  from 
A  to  Y,  and  to  declare  /  :  A  >— »  Y  is  to  say  that  /  is  one  such  total  bijection. 
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D.3.1  Name 

©  —  Functional  overriding 


D.3.2  Definition 

fixity  leftfun  0  © 


_©_ :  (Z 7)  X  (X F)  ^  (Z  y) 


v/,ff  :Z-H-  y  • 

f®9  =  {{domg)<f)Ug 


Description 

If  /  and  g  are  both  functions  from  Z  to  7 ,  then  the  functional  overriding  of  /  by  ^  is  the  function  g 
together  with  such  pairs  of  /  as  have  first  elements  different  from  the  first  element  of  any  pair  in  g. 
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D.4  Numbers  and  finiteness 

Name 
N 
Z 

+,-,*,div,  mod 

<,<,>,> 

Definition 

fixity  leftfun  0  _  +  - 
fixity  leftfun  0  _  ~  _ 
fixity  leftfun  1  _  *  _ 
fixity  leftfun  1  ^div^ 
fixity  leftfun  1  ^mod^ 
fixity  leftfun  3 
fixity  rel  _  <  _ 
fixity  rel  _  <  _ 
fixity  rel  _  >  _ 
fixity  rel  _  <>  _ 

[Z] 

N:PZ 

-  +  Zx  Z-^Z 

_div_,_mod_:  Zx  (Z\  {0})  — >Z 
_-:Z^Z 

—  Z  < — >  Z 

N={n:Z|n>0} 

...  other  definitions  omitted... 


—  Natural  numbers 

—  Integers 

—  Arithmetic  operations 

—  Numerical  comparison 


Description 

The  natural  numbers  are  the  integers  from  zero  upwards.  The  type  of  N  is  PZ,  since  N  is  a  set  of 
integers.  The  declaration  n  :  N  makes  Z  the  type  of  n,  and  entails  the  property  n  >  0. 
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Name 

Ni  —  Strictly  positive  integers 
succ  —  Successor  function 

Definition 

succ  :  N  — N 
V  n  :  N  •  succ{n)  =  n  +  l 

Description 

The  strictly  positive  numbers  N  axe  the  natural  numbers  except  zero. 

The  successor  of  any  natural  number  is  the  next  natural  number  in  ascending  order. 
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Name 

—  Iteration 


Definition 

F=m-- 

iter  :Z^{X 

yR:X^X  * 

iter  0  i?  =  id  X  A 

(V  fc  :  N  •  iter  {k  +  l)/2  =  R  ;  {iter  k  R))  A 
(Vfc  :  N  •  iter  {—k)R  =  iter  k  {R~)) 


Description 

The  iteration  of  a  relation  R  :  X  X  hy  zero  is  the  identity  relation  on  the  set  X. 

The  iteration  of  a  relation  J?  :  Z  X  by  one  is  the  relation  R. 

The  iteration  of  a  relation  R  :  X  ■<— >•  X  by  an  integer  greater  than  one  is  the  composition  of  R  with  its 

iteration  by  the  next  lower  integer. 

The  iteration  of  a  relation  i?  :  A”  <->  X  by  an  integer  less  that  zero  is  the  iteration  of  the  inverse  of  R 
by  the  corresponding  positive  integer.  Thus  the  iteration  of  J?  by  -1  is  the  inverse  of  R. 

The  form:  iter  k  R  is  usually  written  i?*. 
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Name 

. .  —  Number  range 

Definition 

fixity  leftfun  0  — 

_ :ZxZ-->PZ 

Va,6  :Z* 

a.,b  =  {k:Z\a<k<b} 

Description 

If  a  and  b  are  integers,  and  a  is  less  than  6,  the  number  range  a.. 6  contains  a,  b  and  any  integers 
between. 

If  a  is  equal  to  6,  the  number  range  a.. 6  is  a  singleton  set  containing  a  only. 

If  a  is  greater  than  6,  the  number  range  a..b  is  an  empty  set  of  integers. 

The  number  range  a.. 6  is  always  finite,  and  if  6  >  a  its  size  is  b  —  a  +  1. 
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Name 

F  —  Finite  sets 

“  Non-empty  finite  sets 
#  —  Number  of  members  of  a  set 


Definition 

FX  =={5:PX  l3n:N#3/:l..n->5*ran/  =  5} 
F^X  ==¥X\{0} 


[=w= 

#:¥X^N 


V5:FX. 

#5  =  (^n:N|(3/:l..n>-^5*  ran  /  =  5)) 


Description 

A  set  is  finite  if  its  members  can  be  put  into  one-to-one  correspondence  with  the  natural  numbers  fi:‘om 
1  up  to  some  limit.  F  A  is  the  set  of  all  finite  subsets  of  A.  F  A  is  a  subset  of  P  A.  If  A  is  finite,  then 
it  is  a  member  of  F  A. 

The  non-empty  finite  subsets  of  X  are  the  finite  subsets  of  X  except  the  empty  set. 

The  number  of  members  of  a  finite  set  is  the  upper  limit  of  the  number  range  starting  with  1  that  can 
be  put  into  one-to-one  correspondence  with  the  members  of  the  set. 
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Name 

-fH-  —  Finite  partial  functions 
HH  —  Finite  partial  injections 

Definition 

fixity  leftfun  0  hh 
fixity  leftfun  0  hh> 

X  Y  ==  {f  :  X  Y  \  dom  f  e¥X} 

X>^^Y  =={X-^Y)n{Xy+^Y) 


Description 

The  finite  partial  functions  from  X  to  Y  are  the  partial  functions  from  X  to  F  whose  domains  are 
finite  sets. 

The  finite  partial  injections  from  X  to  F  are  the  partial  injections  from  X  to  F  whose  domains  are 
finite  sets. 
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Name 

mm,  max  —  Minimum  and  maximum  of  a  set  of  numbers 


Definition 


min 

■PjZ- 

-H-  Z 

max 

“+■>  Z 

min 

=  {S 

:PiZ; 

m  :  Z  1 

m 

e  S  A 

(Vn  :  S'* 

VI 

n) 

•  S 

m  } 

max 

=  {S 

:PlZ; 

m  :  Z  1 

m 

€  5  A 

(Vn  :  5* 

m  > 

n) 

•  5 

m  } 

Description 

The  minimum  of  a  non-empty  set  of  integers  that  has  a  least  member  is  the  least  member.  Sets  of 
integers  that  have  no  least  member  are  not  in  the  domain  of  min.  If  a  <  6,  min  a..b  =  a. 

The  maximum  of  a  non-empty  set  of  integers  that  has  a  greatest  member  is  the  greatest  member.  Sets 
of  integers  that  have  no  greatest  member  are  not  in  the  domain  of  max.  If  o  <  6,  maxo..6  =  b. 
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D.5  Sequences 
Name 

seq  —  Finite  sequences 

seqi  —  Non-empty  finite  sequences 

iseq  —  Injective  sequences 

Definition 

seqX  ==  {/  :  Nhh-  X  I  dom/  =  1 . .  #/  } 
seqi  =={/:seqX|#/>0} 
iseq  X  ==  seq  X  fl  (N  >-h-  X) 


Description 

A  sequence  is  a  finite  aggregate  of  values  of  the  same  type  in  which  each  value  can  be  identified  by 
its  position  in  the  sequence.  The  formal  definition  establishes  a  sequence  as  a  partial  function  relating 
the  numbers  from  the  set  l..n  for  some  n  (the  domain  of  the  sequence)  to  the  values  (the  range  of 
the  sequence),  seq  A  is  the  set  of  all  finite  sequences  of  values  of  type  X.  The  declaration  S  :  seq  X 
says  that  S  is  one  such  finite  sequence.  Since  a  sequence  is  a  function  (i.e.  a  set  of  ordered  pairs),  a 
sequence  might  be  empty,  and  the  function  application  notation  S  i  can  be  used  to  denote  the  element 
at  position  i,  provided  that  i  is  in  the  domain  of  the  sequence. 

seqi  X  is  the  set  of  all  non-empty  finite  sequences  of  values  of  type  X.  The  declaration  s  :  seq^  X  says 
that  s  is  such  a  non-empty  finite  sequence,  seq^  X  is  a  subset  of  seq  X . 

iseqX  is  the  set  of  all  injective  finite  sequences  of  values  of  type  X.  A  sequence  is  injective  if  no  value 
appears  more  than  once  in  the  sequence.  The  declaration  5  :  iseqX  says  that  5  is  such  an  injective 
finite  sequence,  iseq  X  is  a  subset  of  seq  X . 
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Name 

<>  “  Sequence  brackets 
""  —  Concatenation 


Definition 

MX] 

-  :  seq  X  x  seq  X  — >  seq  X 

W  s^t  :  seqX  • 

5^i  =  5U{n:  dom  ^  •  n  +  #5  t{n)  } 


Description 

The  brackets  <  >  can  be  used  for  enumerated  sequences.  The  empty  enumeration  is  the  empty  function. 
A  singleton  enumeration  is  the  function  that  maps  1  to  the  element  in  the  enumeration.  The  function 
that  extends  an  enumeration  is  the  concatenation  function. 

Concatenation  is  a  function  of  a  pair  of  sequences  of  values  of  the  same  type  that  denotes  a  sequence 
that  begins  with  the  first  sequence  and  continues  with  the  second.  Either  or  both  of  the  sequences 
might  be  empty.  If  either  sequence  is  empty,  the  result  is  the  other  sequence. 
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Name 

head^  last,  tail,  front  -  Sequence  decomposition 


Definition 


Description 

If  5  is  a  non-empty  sequence  of  values  of  type  X,  then  head  S  is  the  value  of  type  X  that  is  first  in  the 
sequence.  Empty  sequences  are  not  in  the  domain  of  head. 

If  5  is  a  non-empty  sequence  of  values  of  type  X,  then  last  S  is  the  value  of  type  X  that  is  last  in  the 
sequence.  Empty  sequences  are  not  in  the  domain  of  last. 

If  5  is  a  non-empty  sequence  of  values  of  type  X,  then  tail  S  is  the  sequence  of  values  of  type  X  obtained 
from  S  by  discarding  the  first  member.  Empty  sequences  are  not  in  the  domain  of  tail. 

If  5  is  a  non-empty  sequence  of  values  of  type  X,  then  fronts  is  the  sequence  of  values  of  type  X 
obtained  from  S  by  discarding  the  last  member.  Empty  sequences  are  not  in  the  domain  of  front. 
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Name 

rev  —  reverse 


Definition 

f=[X]- . 

rev  :  seq  X  — >  seq  X 
V  5  :  seq  X  • 

rev  s  =  (An  :  dom5  •  s{#s  —  n  +  l)) 


Description 

The  reverse  of  a  sequence  is  the  sequence  obtained  by  taking  its  members  in  the  opposite  order. 
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Name 


f  —  Filtering 


Definition 


f  _  :  seq  X  xFX  — >  seq  X 


'iV  :FX  • 

()\V  =  {)A 
{\/x:X» 

{x€V  =i^{x)\V  =  (x))  A 
{xiV=^{x)\V  =  (»)  A 
(Vs,  t :  seq Z  • 

i{s-t)\V  =  is\V)-it\  V)) 


Description 

The  filter  of  a  sequence  of  values  of  type  X  by  a  set  of  values  of  type  X  is  the  sequence  obtained  from 
the  original  by  discarding  any  members  that  are  not  in  the  set. 
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Name 

—  Distributed  concatenation 


Definition 

^ I :  seq(seq  X)  — >•  seq  X 

''/{)  =  0  ^ 

Vs  ;  seq  A"  •  '"/{s)  =  s 
q,r  :  seq(seq  A)  • 

^/(9^r)  =  r/g)-r/r) 


Description 

The  distributed  concatenation  of  a  sequence  of  sequences  of  values  of  type  A  is  a  sequence  of  values  of 
type  A  obtained  by  concatenating  the  lesser  sequences  in  the  order  in  which  they  appear  in  the  greater 
sequence. 
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Name 

disjoint  —  Disjointness 
partition  —  Partitions 


Definition 

disjoint  -  :  P(/  -h-  P  X) 

_  partition  _:(/-+>  P  X)  ^  P  X 

V5:/-H.PZ;  T:TX* 

(disjoints 

(V i,j  :  dom  S  |  t  7^  j  •  S{i)  n  S(j)  =  0))  A 
(S  partition  T 

disjoint  S  A  U{  i  :  dom  S*S(i)}  =  T) 


Description 

An  indexed  family  of  sets  is  disjoint  if  no  two  members  having  distinct  indexes  have  any  members  in 
common. 

An  indexed  family  S  of  sets  partition  a  set  T  if  S  is  disjoint  and  the  union  of  all  the  members  of  S  is 
T. 
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D.  6  Bags 

D.6  Bags 
Name 

bag  —  Bags 
count  —  Multiplicity 
E  —  Bag  membership 

Definition 

bagX-=:X^Ni 


pW 

count :  bag  X  {X  — yN) 

—  E  —  I  ^  — y  bag  X 

Wx:X;B  :hagX  • 

count  B  =  {Xx  :  X  •  0)  ^  B  A 
X  E  B  X  e  dom  B 


Description 

A  bag  represents  an  aggregate  in  which  order  is  not  important,  but  in  which  a  given  value  can  occur 
several  times.  A  bag  of  values  of  type  A  is  a  function  whose  domain  is  a  subset  of  X  and  whose  range 
is  a  set  of  strictly  positive  natural  numbers. 

The  count  of  a  bag  of  values  of  type  X  is  a  function  that  extends  the  bag  function  by  relating  every 
member  of  X  that  is  not  is  the  domain  of  the  bag  to  zero. 

A  value  x  :  X  is  said  to  be  in  j5  :  bagX  if  and  only  if  x  is  in  the  domain  of  B, 
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Name 

W  —  Bag  union 


Definition 

F=[^]  ■  = 

_  y  _  :  bag  X  X  bag  X  — >  bag  X 


yB,C  :ha.gX;x:X  • 

count  {B  y  C)x  =  count  5  x  -f  count  C  x 


Description 

The  bag  union  of  two  bags  is  the  bag  that  relates  every  member  of  the  domain  of  either  bag  to  the  sum 
of  its  occurrences  in  the  two  bags. 
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Name 

items  -  Bag  of  elements  of  a  sequence 


Definition 

MX]-- . 

items  :  seq  X  — >  bag  X 
V  s  :  seq  X;  x  :  X  • 

count  {items  s)x  =  #{i  :  dom  s  |  s{i)  =  x} 


Description 

The  items  of  a  sequence  of  values  of  type  X  is  a  bag  such  that  the  range  of  the  sequence  and  the  domain 
of  the  bag  are  the  same,  and  the  each  value  in  the  domain  of  the  bag  is  related  to  the  number  of  indexes 
in  the  sequence  at  which  that  value  occurred. 

□ 
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E.l  Introduction 

The  Interchange  Format  defines  a  portable  representation  of  Z,  allowing  Z  documents  to  be  trans¬ 
mitted  between  diflFerent  products  or  machines.  The  most  suitable  means  of  communication  is  the  use 
of  text  files  in  which  the  character  set  is  limited  for  portability  reasons.  The  Interchange  Format  defines 
a  syntax  for  such  text  files. 

The  basis  for  the  Interchange  Format  is  the  ISO  Standard  Generalized  Markup  Language  (SGML). 
SGML  permits  the  structure  of  texts  to  be  represented  and  encoded  in  a  standard  form,  convenient  for 
storage,  editing,  retrieval  and  processing.  The  SGML  Standard  is  defined  in  [12].  A  general  description 
of  the  aims  and  principles  of  SGML,  together  with  an  annotated  version  of  the  standard,  is  included  in 
The  SGML  Handbook  by  C.  F.  Goldfarb  [9].  Case  studies  and  applications  in  SGML  are  described  in 
the  work  of  the  Text  Encoding  Initiative  reported  in  [22]. 

The  structure  of  this  Appendix  is  as  follows: 

•  section  E.2  describes  the  scope  of  the  Interchange  Format  —  i.e.  the  facilities  offered  by  the 
Format; 

•  section  E.3  contains  an  informal  description  of  SGML; 

•  section  E.4  defines  the  Interchange  Format; 

•  section  E.5  presents  explanatory  material  and  examples  of  the  use  of  the  Interchange  Format. 
E.2  Scope  of  the  Interchange  Format 

The  Interchange  Format  allows  a  distinction  to  be  made  between  formal  text  and  other  text  included  in 
a  Z  document.  The  Interchange  Format  does  not  prescribe  the  structure  of  all  parts  of  a  Z  document; 
in  particular  it  does  not  define  the  internal  structure  of  informal  text. 

As  one  possible  application  of  the  Interchange  Format  is  to  transmit  a  Z  document  for  Z  syntax  checking, 
the  format  is  sufficiently  liberal  to  permit  syntactically-incorrect  Z  to  be  written.  The  format  thus 
prescribes  markup  only  for  the  higher  levels  of  the  Z  syntax  hierarchy.  In  most  cases  this  is  at  the 
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level  of  a  Z  paragraph,  although  for  axiomatic  and  ‘boxed’  definitions  there  is  scope  for  creating  a  more 
detailed  markup  if  desired  (e.g.  in  order  to  indicate  a  presentation  format). 

For  a  Z  document  to  be  syntactically  correct  when  written  in  the  Interchange  Format,  it  must  conform 
at  the  higher  levels  to  the  markup  defined  in  this  Appendix,  and  at  the  lower  levels  (e.g.  predicate  or 
expression  level)  to  the  Z  Concrete  Syntax,  with  all  mathematical  symbols  replaced  by  the  alphanumeric 
representations  discussed  in  Section  E.4.3. 

The  Interchange  Format  also  provides  markup  for  requirements  which  are  additional  to  the  prime 
requirement  for  encoding  the  structure  of  the  Z  in  a  document.  The  following  additional  requirements 
are  accommodated; 


•  identification  of  informal  Z  fragments,  i.e.  Z  fragments  which  do  not  belong  to  the  formal  part  of 
a  Z  document; 

•  indication  of  particular  presentation  formats,  e.g.  whether  a  vertical  or  horizontal  style  should  be 
employed  for  a  schema  definition; 

•  allocation  of  identifiers  to  Z  paragraphs,  e.g.  so  that  associations  between  Z  operation  schemcis 
and  data-fiow  diagrams  can  be  made,  or  so  that  Z  definitions  can  be  indexed; 

•  logical  grouping  of  Z  paragraphs  independently  of  the  positions  they  occupy  in  the  document, 
e.g.  so  that  the  group  can  be  considered  as  a  unit  for  type-checking  purposes,  or  that  ‘units  of 
conservative  extension’  can  be  identified  for  subsequent  processing  by  a  proof  tool; 

•  labelling  of  ‘stacked’  predicates  in  an  axiomatic  or  ‘boxed’  definition. 


E.3  Introduction  to  SGML 

This  section  provides  an  introduction  to  SGML,  sufficient  for  the  understanding  of  the  definition  of  the 
Interchange  Format  in  Section  E.4.  More  comprehensive  descriptions  of  SGML  are  given  in  fl2l  and 
[9].  ^  J 

Examples  of  text  written  in  SGML  are  printed  with  a  fixed-width  font  (the  tt  font  in  lATgK)  as  follows: 
<tag>  text  </tag> 


E.3.1  SGML  Element  Definitions 

Structures  are  described  in  the  Interchange  Format  by  means  of  SGML  elements.  Elements  are  delim¬ 
ited  by  start-tags  and  end-tags.  A  start-tag  is  of  the  form  <name>,  where  name  is  the  generic  identifier 
of  the  delimited  element.  The  end-tag  is  of  the  form  </name>.  For  example,  a  particular  Z  given  set 
definition  may  be  written  in  the  Interchange  Format  as: 

<givendef>  NAME,  DATE  </givendef> 

The  internal  structure  of  a  general  SGML  element  is  itself  defined  in  SGML  by  means  of  a  formal  SGML 
element  declaration.  The  components  of  an  element  declaration  are: 
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1.  the  name  of  the  element; 

2.  two  characters  (separated  by  a  space)  which  specify  the  minimisation  rules  for  the  element; 

3.  the  content  model  of  the  element. 


The  minimisation  rules  indicate  whether  the  start-tags  or  end-tags  may  be  omitted  in  instances  of  the 
element.  The  first  character  in  the  pair  corresponds  to  the  start-tag  and  the  second  to  the  end-tag.  The 
character  or  ‘o’  indicates  that  the  corresponding  tag  respectively  must  be  present  or  may  be  omitted. 

The  content  model  specifies  what  any  occurrences  of  the  element  may  legitimately  contain.  Contents 
may  be  specified  in  terms  of  other  elements  and  special  reserved  words.  Ultimately  all  elements  consist 
of  ‘parsed  character  data’  (represented  in  element  declarations  by  the  reserved  word  #PCDATA),  which 
contains  any  valid  character  data  but  not  further  elements.  Further  structural  information  concern¬ 
ing  elements  which  are  constituents  of  the  declared  element  is  provided  by  the  use  of  occurrence 
indicators  and  group  connectors. 

Occurrence  indicators  define  how  many  times  a  constituent  element  may  occur  in  instances  of  the  defined 
element  and  are  placed  at  the  end  of  the  constituent  element.  The  following  occurrence  indicators  are 
used  in  this  Appendix: 


•  a  question  mark  (?)  indicates  that  the  preceding  element  occurs  at  most  once; 

•  an  asterisk  (*)  indicates  that  the  preceding  element  may  be  absent  or  occurs  one  or  more  times; 

•  a  plus  sign  (+)  indicates  that  the  preceding  element  occurs  one  or  more  times. 

Group  connectors  specify  the  ordering  of  constituent  elements.  The  following  connectors  are  used  in 
this  Appendix: 

•  a  vertical  bar  (()  indicates  that  only  one  of  the  components  it  connects  may  appear; 

•  a  comma  (,)  indicates  that  the  components  must  appear  in  that  order. 


For  example  the  element  definition  for  a  Z  schema  declaration  is  given  as: 


<! ELEMENT  schemadef 

((#PCDATA  I  sub  I  mixednaine)  +  ,  formals?,  decpairt?,  axpcirt?)  > 


Occurrences  of  this  element  thus  consist  of  a  sequence  of  parsed  character  data,  subscript  and  mixed 
name  elements  (representing  the  name  of  the  schema),  followed  by  an  optional  element  which  holds 
the  formal  parameters  of  the  definition,  followed  by  elements  representing  the  optional  declaration  and 
axiomatic  parts  of  the  schema  definition.  The  start-tag  and  end-tag  of  the  schema  definition  must  both 
be  present. 
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E.3.2  SGML  attribute  declarations 

In  SGML,  attributes  are  used  to  provide  information  associated  with  elements.  The  Interchange 
Format  employs  attributes  to  encode  layout  information  and  other  information  which  is  not  considered 
to  be  part  of  the  structure  of  a  Z  specification.  For  example,  the  Interchange  Format  defines  a  ‘style’ 
attribute  for  schema  definitions  which  permits  an  indication  of  whether  the  definition  should  be  in 
vertical  or  horizontal  form.  An  occurrence  of  a  ‘schemadef’  element  may  thus  contain  an  attribute- 
value  pair  inside  the  element’s  start-tag;  for  example: 


<schemadef  style=vert>  S  . . .  </schemadef > 


An  SGML  attribute  declaration  specifies  the  name(s)  of  the  element(s)  to  which  the  attributes  are 
attached,  followed  by  a  list  of  rows,  each  of  which  consists  of  the  name  of  the  attribute  being  declared 

Its  type,  and  an  optional  default  value.  A  type  may  be  given  as  a  collection  of  explicit  values,  or  as  one 
of  the  following  special  keywords: 


CDATA 

ID 

NMTOKEN 

NUMBER 


the  attribute  value  may  contain  any  valid  character  data  and  must  be  delimited  by 
double  quotation  marks; 

indicates  that  a  unique  identifying  value  will  be  supplied  for  each  instance  of  the 
element; 

the  attribute  value  is  a  name  token  (i.e.  any  alphanumeric  string); 
the  attribute  value  is  a  number. 


The  default  value  for  an  attribute  may  be  denoted  as  one  of  the  set  of  explicit  values  defined  for  an 
attribute;  alternatively  it  may  be  one  of  the  following  special  values: 


#IMPLIED  a  value  need  not  be  supplied; 
#REC!UIRED  a  value  must  be  supplied. 


E.3. 3  SGML  entities 

An  SGML  entity  is  a  named  part  of  a  marked-up  document.  An  example  of  an  entity  declaration  is: 
<! ENTITY  ZBS  'Z  Steindard,  version  l.O'  > 

References  to  entities  are  contructed  by  prefixing  the  name  of  the  entity  with  an  ampersand  character 
(&)  and  delimiting  the  end  of  the  name  with  a  semicolon,  space  or  end-of-file.  Here  is  an  example  of 
an  entity  reference: 


We  are  now  in  a  position  to  issue  the  &ZBS; . 
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The  entity  reference  in  this  document  fragment  would  be  expanded  by  an  SGML  parser  as: 

We  are  now  in  a  position  to  issue  the  Z  Standard,  version  1.0. 

In  the  Interchange  Format,  SGML  entities  are  used  to  represent  certain  Z  symbols  or  words.  The 
associations  between  the  alphanumeric  representation  of  mathematicail  symbols  or  words  and  their  local 
codes  should  be  defined  in  SGML  entity  declarations.  However  -  since  local  word  processor  codes  may 
differ  -  section  E.4.3  presents  a  scheme  in  which  the  entity  names  used  in  the  Interchange  Format  are 
listed  against  the  usual  presentation  format  of  the  corresponding  Z  symbols  or  words. 
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E.4  Definition  of  the  Interchange  Format 


This  section  presents  the  definition  of  the  Interchange  Format  as  a  collection  of  SGML  declarations 
Explanatory  material  and  examples  of  the  use  of  the  Interchange  Format  are  also  given  in  Section  E.5.' 


An  SGML  Document  Type  Definition  (DTD)  defines  the  syntax  of  SGML-conformant  documents  in  a 

style  which  is  readable  by  SGML  parsers.  The  Interchange  Format  does  not  warrant  a  full  DTD  for 
two  reasons: 


•  the  format  does  not  specify  the  structure  of  the  informal  text  in  a  Z  document; 

•  the  entity  declarations  are  implementation-dependent. 


A  DTD  consists  of  a  header,  followed  by  a  body  containing  the  element  declarations,  attribute  dec¬ 
larations  and  entity  declarations.  The  definition  of  the  Interchange  Format  presented  in  this  Section 
may  be  considered  as  the  partial  body  of  a  DTD  [paHial  because  the  entity  declarations  are  not  given 
explicitly);  it  is  also  equivalent  to  a  definition  in  BNF  of  the  structure  of  the  Interchange  Format 
Newlines  in  a  Z  document  are  not  significant  in  the  translation  to  the  Interchange  Format  except  where 
they  serve  to  separate  predicates  or  declarations. 

It  is  unlikely  that  this  Interchange  Format  could  ever  accommodate  every  function  required  by  its  users. 
However,  any  collection  of  SGML  declarations  (such  as  those  which  define  this  Interchange  Format)  may 
be  replaced  or  enhanced  by  the  pre-insertion  of  additional  SGML  declarations.  Such  a  ‘customisation’ 
of  the  Interchange  Format  would  be  acceptable  by  SGML  parsers. 


E.4.1  Element  declarations 

These  declarations  define  the  higher-level  structure  of  the  Z  paragraphs  in  a  Z  document  written  in  the 
Interchange  Format.  They  correspond  closely  to  the  appropriate  constructs  of  the  Z  Concrete  Syntax 
Note  that  no  element  minimisation  options  are  offered;  the  start  and  end  tags  must  both  be  present  for 
each  element  instance. 

There  are  two  top-level  elements: 


•  the  Z  element  represents  a  sequence  of  Z  paragraphs; 

•  the  informalZ  element  represents  a  fragment  of  mathematics  which  does  not  belong  to  the  formal 
part  of  the  specification  document. 


The  Z  element  contains  a  (possibly  empty)  sequence  of  individual  Z  paragraph  elements  which  constitute 
(part  of)  a  formal  specification. 


<! ELEMENT  Z 

(fixity  I  givendef  |  axdef  |  constraint 
I  schemadef  |  gendef  |  abbrevdef 
(  goal  I  structsetdef)*  > 


Z  Notation  Version  1.1  30lh  June  1995 


189 


E  INTERCHANGE  FORMA  T  -  NORMA TIVE  ANNEX 


The  inf  ormalZ  element  defines  a  fragment  of  mathematics  which  is  not  to  be  considered  as  a  formal 
part  of  the  specification;  these  fragments  may  be  Z  elements,  declaration  elements,  or  a  sequence  of 
parsed  character  data,  subscript  elements  and  mixed  name  elements  (corresponding  to  unstructured 
fragments  of  mathematics). 

<! ELEMENT  informalZ 

(Z  I  declaration  )  (#PCDATA  |  sub  |  mixedname)+)  > 

Elements  representing  goals,  top-level  constraints,  declarations,  abbreviation  definition  bodies,  predi¬ 
cates,  fixity  template  expressions,  given  set  definitions,  declarations  of  formal  parameters,  subscripts 
and  operator  names  in  fixity  template  definitions  all  consist  of  an  unstructured  sequence  of  parsed 
character  data,  subscript  elements  and  mixed  name  elements. 

<! ELEMENT  (goal  |  constraint  |  declaration 
I  body  I  predicate  |exp  |  givendef 
I  formals  |  sub  |  nameairg)  -  - 

(#PCDATA  I  sub  I  inixedname)+  > 

Elements  representing  axiomatic  definitions,  schema  definitions  and  generic  definitions  contain  decpart 
and  axpart  elements;  the  latter  element  is  optional,  as  is  also  the  decpart  element  for  schema  defi¬ 
nitions.  Schema  definitions  and  generic  definitions  may  contain  a  formals  element  (representing  the 
declaration  of  formal  parameters).  The  name  introduced  by  a  schema  definition  is  modelled  as  an 
unstructured  sequence  of  parsed  character  data,  subscript  elements  and  mixed  name  elements. 

<! ELEMENT  axdef  -  -  (decpart,  axpart?)  > 

<! ELEMENT  schemadef  -  - 

((#PCDATA  I  sub  I  mixedname)+,  formals?,  decpart?,  axpart?)  > 

<! ELEMENT  gendef  -  -  (formals?,  decpart,  axpeirt?)  > 

The  element  representing  an  abbreviation  definition  consists  of  the  name  introduced  by  the  definition 
(which  is  modelled  as  an  unstructured  sequence  of  parsed  character  data,  subscript  elements  and  mixed 
name  elements),  an  optional  formals  element  which  represents  the  declaration  of  formal  parameters, 
and  a  body  element  which  represents  the  right-hand  side  of  the  abbreviation  definition. 

<! ELEMENT  abbrevdef 

((#PCDATA  I  sub  I  mixedname)+,  formals?,  body)  > 

The  element  representing  a  structured  set  definition  consists  of  the  name  introduced  by  the  definition 
(which  is  modelled  as  an  unstructured  sequence  of  parsed  character  data,  subscript  elements  and  mixed 
name  elements)  and  a  non-empty  sequence  of  branch  elements. 

<! ELEMENT  structsetdef  -  - 

((#PCDATA  I  sub  I  mixedname)+,  branch+)  > 
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The  element  representing  a  branch  of  a  structured  set  definition  consists  of  a  constructor  name  (which 

IS  modelled  as  an  unstructured  sequence  of  parsed  character  data,  subscript  elements  and  mixed  name 
elements)  and  an  exp  element. 


<! ELEMENT  branchf 


((#PCDATA  I  sub  I  mixedname)+,  exp)  > 


The  element  representing  the  axiomatic  part  of  a  ‘bOxed’  definition  consists  of  a  sequence  of  predicate 
elements,  representing  the  predicates  which  are  intended  to  be  separated  by  the  weakly-binding  con- 
junction  denoted  by  significant  newlines. 


<C  I  ELEMENT  axpart  -  -*  (predica‘te+)  > 


The  element  representing  the  declaration  part  of  a  ‘boxed’  definition  consists  of  a  sequence  of  declaration 

e  ements,  each  representing  a  collection  of  declarations  which  is  separated  from  other  such  collections 
by  significant  newlines. 


<! ELEMENT  decpart  -  -  (declaration+)  > 


The  element  which  represents  a  fixity  statement  consists  of  an  unstructured  sequence  of  parsed  character 
data  subscript  elements  and  mixed  name  elements  (modelling  the  first  part  of  the  operator  name 
introduced  by  the  statement)  and  a  (possibly  empty)  sequence  of  namearg  and  exparg  elements  which 
represents  the  rest  of  the  fixity  template.  Each  exparg  element  consists  of  three  exp  elements  followed 
by  an  unstructured  sequence  of  parsed  character  data,  subscript  elements  and  mixed  name  elements 
which  models  part  of  the  operator  name. 


<! ELEMENT  fixity 

((#PCDATA  I  sub  I  mixednaine)+,  (namearg  |  exparg)*)  > 

< ! ELEMENT  exparg  -  - 

(exp,  exp,  exp,  (#PCDATA  |  sub  |  mixedname)+)  > 


The  element  which  represents  a  mixed  name  consists  of  parsed  character  data.  A  mixed  name  element 
must  be  employed  in  cases  where  a  Z  name  consists  of  more  than  one  entity  reference  or  of  a  mixture 
of  entity  references  and  normal  characters. 


<! ELEMENT  mixedname  -  -  #PCDATA  > 


E.4.2  Attribute  declarations 


The  attribute  declarations  permit  the  association  of  additional  information  with  occurrences  of  elements 
in  a  Z  document  written  in  the  Interchange  Format. 

The  attributes  id  and  group  permit  identification  and  logical  grouping  of  Z  paragraphs  respectively. 
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<!AmiST 

(givendef  |  axdef  |  constraint  |  schemadef  |  gendef 
I  goal  I  abbrevdef  |  struct setdef) 
id  ID  #IMPLIED 
group  NMTOKEN  #IMPLIED  > 

The  attributes  style  and  purpose  define  the  layout  and  intended  use  of  a  schema  definition  respectively. 

< ! ATTLIST  schemadef 

style  (vert  |  horiz)  vert 

purpose  (state  |  operation  |  datatype)  #IMPLIED  > 

The  attribute  label  permits  informal  annotation  of  each  member  of  the  ‘stack’  of  predicates  which 
constitutes  the  axiomatic  part  of  a  boxed  definition. 

<! ATTLIST  predicate  label  CDATA  #IMPLIED  > 

The  following  attributes  are  used  with  the  fixity  element: 

•  the  attribute  category  indicates  whether  the  defined  operator  is  a  relation,  left-associative  func¬ 
tion  or  right-associative  function; 

•  the  attribute  prec  indicates  the  binding  priority  of  the  defined  function  (this  attribute  is  not 
required  if  the  value  of  category  is  rel); 

•  the  attributes  first  arg  and  lastairg  indicate  the  kind  of  first  and  last  argument  (if  any)  respec¬ 
tively  in  the  fixity  statement. 

<! ATTLIST  fixity 

category  (leftfun  |  rightfun  |  rel)  #REQUIRED 
prec  #NUMBER  #IMPLIED 

(first arg  |  last arg)  (normal  |  type)  #IMPLIED  > 

The  attribute  midarg  of  the  namearg  element  indicates  the  kind  of  argument  which  appears  just  before 
the  part  of  the  operator  name  presented  in  the  namearg  element. 

< ! ATTLIST  namearg 

midarg  (normal  |  type)  #REQUIRED  > 


E.4.3  Entity  declarations 


Editor’s  note;  This  subsection  lists  examples  of  entity  definitions  that  might  be  required  for  the  toolkit. 
It  will  be  updated  when  a  final  version  of  the  toolkit  has  been  developed. 
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Entity  declarations  are  used  to  define  alphanumeric  denotations  for  certain  Z  symbols  and  words.  The 
entity  declarations  for  the  Interchange  Format  are  not  presented  in  the  conventional  SGML  format 
because  of  the  dependence  of  the  internal  representation  of  mathematical  symbols  or  words  on  the 
implementation  of  each  user’s  Z  document  processor.  The  mode  of  declaration  used  in  this  Standard  is 
to  present  tables  which  record  the  association  of  each  entity  name  with  the  corresponding  mathematical 
symbol  or  word.  These  tables  are  presented  in  the  Lexis  Section  of  this  Standard. 

Many  of  the  entity  names  used  in  the  tables  have  already  been  defined  as  standard  in  Appendix  D  of 

[12]. 

In  order  to  encode  names  which  consist  of  more  than  one  entity  reference,  or  of  a  mixture  of  entity 
references  and  normal  text,  “mixed  name”  elements  must  be  employed.  For  example,  the  application 
of  the  function  A  to  the  variable  State  (ie  A  State)  is  encoded  as  ftDelta;  State  (or  &Delta;  State  or 
&Delta  State),  but  the  schema  name  ^State  must  be  encoded  as  any  of  these  alternatives  enclosed 
within  mixedname  element  tags.  The  use  of  the  mixedname  element  indicates  that  the  contents  are  to 
be  considered  as  a  single  name. 

Z  users  may  create  additional  entity  declarations  to  cater  for  new  symbols  introduced  in  their  specifi¬ 
cation  documents.  For  example,  assume  that  the  new  symbol  0  is  to  be  used  in  a  Z  document.  The 
author  of  the  document  must  create  an  entity  declaration  of  the  form 

<!  ENTITY  oslash  SDATA  ’*  oslash** 

— o  enclosing  a  solidus — > 


This  declaration  gives  the  name  oslash  to  the  entity  which  represents  the  symbol  and  identifies  the 
local  code  which  generates  the  presentation  format  0  of  the  symbol.  As  it  is  unlikely  that  other  systems 
possess  this  code,  a  description  of  the  presentation  format  of  the  symbol  is  given  as  a  comment  in  the 
entity  declaration.  Any  receivers  of  the  Z  document  may  then  establish  a  suitable  local  code  for  this 
symbol  in  their  respective  systems. 


Entity  definitions  for  the  toolkit 

Entity  definitions  are  provided  only  for  the  following  classes  of  toolkit  member: 

•  non-alphanumeric  members  (apart  firom  the  addition  (4-)  and  multiplication  (*)  symbols,  as  it  is 
assumed  that  these  symbols  are  reasonably  portable); 

•  relations  with  alphanumeric  names  (as  these  are  customarily  presented  in  sans-serif  font); 

•  ‘type  constructors’  (ie  generic  constants  with  set  values)  with  alphanumeric  names  (as  these  are 
customarily  presented  in  Roman  font); 

•  the  functions  dom  and  ran  (as  these  are  customarily  presented  in  Roman  font). 
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E.5  Examples 

This  section  presents  examples  of  the  use  of  the  Interchange  Format.  Thses  examples  are  carefully  chosen 
to  cover  the  more  obscure  aspects  of  the  Format.  The  areas  covered  are  indicated  in  the  subsection 
headings. 


E.5.1  Declaring  infix  identifiers 

Consider  the  following  axiomatic  definition,  which  declares  a  relation  isTwice  which  is  intended  to  be 
used  in  an  infix  manner: 


SYNTAX  REL  NORMAL  isTwice  NORMAL 

^isTwice^  :  N  4-^  N 
V  :  N  •  z  isTwice  j  ^  i  =  2*j 

This  can  be  encoded  in  the  Interchange  Format  as 


<Z> 

<fixity  c  at  egory=r  e  1  f  ir  s  t  arg=iiormal  las  t  arg=normal  > 
isTwice  </fixity> 

<axdef> 

<decpart> 

<declaration> 

_isTwice_:  &Nat;  ferel;  &Nat; 

</declaration>  </decpart> 

<axpart> 

<predicate> 

feforall;  i,  j:  &Nat;  febull;  i  isTwice  j  feiff;  i  =  2*j 
</predicate>  </axpaxt> 

</axdef > 

</Z> 

E.5. 2  Subscripts 
The  axiomatic  definition 

ai,  03  :  N 

03  isTwice  oi 

is  encoded  in  the  Interchange  Format  as: 
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<Z>  <axdef> 

<decpart> 

<declaration> 

a<sub>  1  </sub>,  a<sub>  3  </sub>:  &Nat; 
</declaration>  </decpart> 

<cLxpart> 

<predicate> 

a<sub>  3  </sub>  isTwice  a<sub>  1  </sub> 
</predicate>  </axpart> 

</axdef>  </Z> 


E.5.3  Schema  definitions  and  predicate  labelling 

Consider  the  following  definitions: 

[PERSON,  HOUSE] 


Street _ _ _ _ _ 

inhabits  :  PERSON  hh-  HOUSE 
houses  :  Y HOUSE 

houses  =  ran  inhabits 

\/h  :  houses  •  H^inhabits"^ \{h})  <  4 

/  *  No  house  may  be  occupied  by  more  than  A  persons  *  / 


The  author  of  this  specification  intends  to  accomplish  the  following  objectives: 

•  to  attach  a  label  to  the  second  predicate  in  the  schema  definition; 

•  to  indicate  that  the  schema  definition  should  be  displayed  in  vertical  form; 

•  to  indicate  (to  a  specification  checker,  for  example)  that  the  schema  Street  defines  the  state  of  a 
system. 

These  objectives  can  be  attained  in  the  Interchange  Format  with  the  following  encoding: 


<Z> 

<givendef>  PERSON,  HOUSE  </givendef> 

<schemadef  style=vert  purpose=state>  Street 
<decpaxt> 

<declco:ation> 

inhabits:  PERSON  fefpfun;  HOUSE  </declaration> 
<declaxation> 

houses:  &pset;  HOUSE  </declaration> 
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<axpart> 

<predicate> 

houses  =  feran;  inhabits  </predicate> 

<predicate 

label='No  house  may  be  occupied  by  more  than  4  persons'> 
feforall;  h:  houses  febull; 

&num;  inhabits  fetilde;  felimg;  felcub;  h  fercub;  ferimg;  &le;  4 
</predicate>  </axpart> 

</schemadef > 

</Z> 


E,5.4  Symbols  in  top-level  definitions 

Note  that  in  the  Interchange  Format  there  are  no  entity  representations  of  the  symbols  immediately 
associated  with  top-level  definitions  such  as  structural  set  definitions  and  abbreviation  definitions.  These 
symbols  axe  subsumed  by  the  element  tags  for  those  definitions.  For  example,  consider  the  following 
abbreviation  definition: 


n  ==  5  -h  a; 


This  definition  is  encoded  in  the  Interchange  Format  as: 


<Z>  <abbrevdef>  n 

<body>  5  +  X  </body>  </abbrevdef >  </Z> 


i.e.  there  is  no  need  in  the  Interchange  Format  for  an  SGML  entity  which  represents  the  ==  symbol 
(although  this  symbol  would  of  course  be  employed  in  the  presentation  format  for  instances  of  the 
abbreviation  element). 

□ 
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Notes  on  this  section  of  the  Z  Standard 

Section  title:  The  Logical  Theory  of  Z 
Section  editor:  Andrew  Martin 
Original  text  by:  Stephen  Brien 
Contributions  by:  Peter  Lupton  ...  (to  be  added) 

Source  file:  logical.tex 

Most  recent  update:  29th  June  1995 

Formatted:  3rd  July  1995 


Editor’s  note:  Draft — comments  and  questions  in' boxes! 


F.l  Preamble 


Editor’s  note:  To  he  supplied  by  Peter  Lupton.  This  chapter  defines  what  the  theorems  of  Z  are, 
discusses  the  relationship  between  logic,  deductive  system,  semantics;  and  soundness.  It  also  describes  how 
other  deductive  systems  (and  logics?)  are  to  be  derived;  what  it  means  for  them  to  be  conformant/sound 
and  complete. 


Editor’s  note:  This  chapter  presents  a  deductive  system  for  Z,  a  deductive  type  system  for  Z  and  equa¬ 
tions  for  free  variables  and  substitution  of  terms  in  Z. 

old  text: 

The  deductive  system  is  a  Gentzen-style  sequent  calculus  in  which  sequents  are  composed  of  paragraphs 
and  predicates.  The  rules  of  the  logic  are  presented  in  a  simplified  form.  The  meta-theorems  of  the  logic 
(theorems  about  the  rules)  permit  the  extension  of  the  rules  into  a  more  practical  form. 

The  loose  definition  of  function  application  and  definite  description  in  the  semantics  permits  a  number 
of  interpretations  of  their  meanings.  This  deductive  system  is  sound  with  respect  to  a  model  in  which  all 
well-typed  expressions  have  a  value. 


F.2  Meta-language 


The  deductive  system  will  be  expressed  using  the  abstract  syntax.  Some  simplifications  will  be  used. 
In  particular,  the  paragraph  keywords  given,  gendef,  abbr  etc.  will  be  omitted.  The  concrete  syntax 
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apparently  now  has  a  leti  :=  «  in  t  construction.  The  deductive  system  is  better  expressed  with 
^  a:  :=  u}  et. 


Editor’s  note:  Stephen  has  ]  b)  P  for  substitution  in  predicates,  and  6 ©  e  for  substitution  in  expressions. 
Our  abstract  syntax  doesn’t  permit  the  first,  BUT  some  of  the  semantic  equivalences  need  predicate  and 
expression  substitution  to  be  distinguished.  I've  used  6  ©  P  for  the  former,  for  the  time  being. 


F.2.1  Meta- Variables 

The  meta-variables  used  in  what  follows  are  members  of  the  following  syntactic  categories: 
n  ::  PAR 

r  ::  PAR  ^...J  PAR 
P,Q,R  ::  PRED 
X  ::  NAME 
b,  e,f,  s,  V  ::  EXP 

S,  T  SCHEMA 
9  ::  DECOR 


F.2.2  Sequent 


Editor’s  note:  We  assume  that  the  Abstract  Syntax  has  been  updated  so  that 
CONJECTURE  =  conj  PAR  f  J  PAR  h  PRED. 


Editor’s  note:  The  abstract  syntax  for  PAR  is  unclear.  It  doesn’t  seem  to  cater  for  all  possibilities.  For 
the  time  being,  this  chapter  uses  Stephen’s  paragraphs. 


The  abstract  syntax  has  a  paragraph  form  CONJECTURE,  which  is  a  sequent: 

nit---jn„i-p  . 

The  meaning  of  this  paragraph  (in  terms  of  the  semantics)  is  described  elsewhere.  For  the  sequent  to 
be  well-formed,  the  free  variables  of  P  must  be  declared  in  flif  •  •  •  tn„.  The  preamble  above  describes 
what  it  means  for  a  sequent  to  be  a  theorem  of  Z;  the  deductive  system  defines  which  sequents  may  be 
deduced  from  which  other  sequents. 

This  chapter  also  presents  type  judgements  of  the  form 
r  I-  e  g  r  . 

This  sequent  means  that,  in  the  specification  F,  the  expression  e  is  well-typed  with  type  r.  The 
following  proof  rules  assume  that  t  is  arbitrary,  it  should  be  established  by  pattern  matching.  For 
predicates  (which  do  not  have  a  type)  we  write  h  P  to  mean  that  the  predicate  P  is  well  typed. 
For  paragraphs  we  write  h  P  ::  to  indicate  that  they  are  well-typed.  Though  the  turnstile  is  the  same 
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as  for  the  deduction  rules,  it  is  used  to  represent  different  kinds  of  relations.  These  assertions  can  be 
distinguished  by  the  syntax  of  the  consequent  (the  antecedent  in  both  cases  being  a  specification). 


Editor’s  note:  What  about  provisos- as- judgements?  (See  Section  F.7.) 


F.2.3  Rules 

The  deductive  systems  consist  of  a  number  of  rules  for  manipulating  sequents.  Inference  rules  will  be 
written 

Rule  =  Ri'^uiises  (Proviso) 

Conclusion  '  ’ 

The  premises  are  a  (possibly  empty)  list  of  sequents: 

Premises  =  Sequent . . .  Sequent 

The  conclusion  is  always  a  single  sequent: 

Conclusion  =  Sequent 

The  Proviso  is  a  decidable  condition  on  the  free  variables  of  the  expressions  and  predicates  in  the  rule. 
The  annotation  t4-  indicates  that  the  rule  can  be  applied  in  both  directions — that  is,  the  rule 


ri-'i' 


n 


r'h$ 

denotes  both  of  the  following  inference  rules 
ri-’j'  ...j 


r'H$ 


and 


A  rule  is  sound  if  whenever  it  is  applied  to  valid  premisses,  a  valid  conclusion  results.  This  is  defined 
in  the  semantics  by  saying  that  the  set  of  environments  supporting  the  premisses  is  a  subset  of  those 
supporting  the  conclusion.  The  rule 


Si  ...  S„ 


N{P) 


Seq 

is  sound  if  and  only  if 

P  =>  {S,  ]}^  n  . . .  n  ]}^  C  ([5eg 

The  following  meta-theorem  holds  for  rules  in  the  deductive  system: 

Theorem  F.l  (Sequent-lifting) 

The  rule  p  |-  p  is  sound  if  and  only  if  the  sequent  P  h-  P  is  a  theorem. 
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This  meta-theorem  states  that  a  theorem  can  be  deduced  from  no  premisses. 

The  semantic  equivalences  for  substitution  are  given  in  tables  in  later  sections.  These  tables  state  the 
semantic  equality  of  various  expressions.  A  theorem  which  permits  the  use  of  semantic-equivalences  in 
proofs  is  the  following. 

Theorem  F.2  (Semantic-equivalence-lifting)  Given  the  semantic- equivalence  for  any  predicates 
or  expressions 

A  =  B 

the  following  inference  rule  is  sound: 

A(^) 

A(5) 


F.2.4  wf 

The  proviso  wf(par)  is  an  abbreviation  stating  that  {par)  is  well-formed  in  that 
(f){par)  n  a{par)  =  0 


F.2. 5  Proofs 

Proofs  in  the  deductive  system  proceed  in  the  way  that  is  usual  for  sequent  calculi:  proofs  are  developed 
backwards,  starting  from  the  sequent  which  is  to  be  proved.  A  rule  is  applied,  resulting  in  fresh  sequents 
which  must  be  proved.  This  process  continues  until  there  are  no  more  sequents  requiring  proof,  in  which 
case  the  original  sequent  is  now  proved. 

A  completed  proof  may  thus  be  represented  as  a  tree,  with  the  proved  sequent  as  the  root  node,  and 
every  leaf  node  containing  an  empty  list  of  sequents.  However,  if  some  of  these  lists  in  the  leaves  are 
non-empty,  then  the  derivation  tree  is  still  useful,  although  it  does  not  represent  a  proof,  it  represents 
a  partial  proof. 

Theorem  F.3  (Tree-squashing)  Suppose  that  we  have  the  derivation  tree: 


Si 


Sii 


-  [R]iP) 


where  each  of  the  rules  R  and  Ri  are  sound  rules,  then  the  derived  rule 


Si  ...  Sji 


[R']{P,Pi) 


is  also  sound. 
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F.3  Inference  rules 

F.3.1  Structural  rules 

Assumption  rules 
p  l_  p  AssumPred 

^ _ g  l_  ^  _  g  AssumDefin{wi{x  :=  e)) 

- ; -  AssumDecl{vii{x  :  5)) 

g  SchemaAss{aS  H  05  =  0) 


Paragraph  and  thinning  rules 

P  A  iZ  h  Q 

Q  t-1-  PredConj 

r  h  p 
njr  H  p 

Thinr{an.  r]<f>P  =  0) 

ritT2inhP  (  ar2n<^n  =  0  \ 
rimT2 1-  p  ^  \aur\4>r2  =  0  ) 

r#^“(“^n^p  =  0) 

F,3.2  Equality  and  substitution 
rhe  =  e 
r  h  u  —  e 

r  f-  e  =  «  ^ 


rfu  z=:  e  h  V  =  e 
rjw  =  e\-  V  =  u 


Trans 


b\  eP 


UseBind 


\-u  =  e 
r  h  u  =  bee 


EquBind{ab  O  0u  =  0) 
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F.3.3  Propositional  calculus 

rhP  ri-{? 


ri-F  A  Q 


Audi 


T\-P  AQ 
TbP 


AndEr 


TbP  AQ 
TbQ 


AndEl 


TbP 
TbPV  Q 


Orir 


TbQ 
TbPV  Q 


Orll 


TbPy  Q 


rtPi-p 

TbR 


TtQbR 


OrE 


TtPbQ 
TbP^  Q 


impi 


TbP  TbPr^Q 
TbQ 


impE 


r  b  false 

ri-F 


falseE 


rt-  P  b  false 
TbP 


notE 


P^Q  = 
-.P  = 
false  ^ 
P  => 


P  ^  Q  AQ  P 
P  =»  false 
P 

true 
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F.3.5  Expression  rules 
Sets 

rtfzjTl-  e  =  {(]  a;  :=  s}  oT  •  ^  £>2 

rt[a:]T  H  t/[,]  €  e  iv  G  a(wf  T)) 

j,|_(Va::s*a:€0^ 

- ^  ^  ~  Seteq{x  ^  </>s  U 
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rhi;  =  ei  V...Vt;^ 
r  h  V  G  {ei, . . . ,  e„} 


ri-3iS'«e  =  » 

T\-  ee{S  •u} 


ti  Setcomp{(t>u  n  a5  =  0) 


Csirtesian  products 

r  h  Vx  ■  i  J  Powerset{x  f  <l>s) 

ThteVs 


_ — —  Tupleequ{l  <  i  <  n) 

r  h  u  =  (ei, . . . ,  Cnj-i 

r  h  U.l  e  Si  A  .  ■  ■  A  M-n  £  5n  Prodmem 

r  h  u  €  Si  X  •  •  •  X  s„ 

rh  u  =  (ei,...,0 - Tuplesel 

r  h  u.l  =  ei  A  . . .  A  u.n  =  e„ 


Labelled  products 


BindEqu 

r  h  ^  il  :=  ei, . . . ,  In  :=  e„)  .x,  -  Ci  (!<*<«) 


r  h  u.ii  =  ei  A  . .  ■  A  u.Xn  -  en  BindSel 
r  h  u  =  ^  ii  :=  ei, . . . ,  In  := 


6}  b  I  =  6.1 


D6(x  e  ab,wfb) 


Schemas 

r  h  e.ii  =  ii  A  •  •  •  A  e.in  — 
“  r  h  e  =  05 


rh  5 


D20 


h  ^  ii:=ii,...,in:=a:nt  eS  t4-  08 

1-5  Q!5={i1)  •  •  •  )  3!n} 
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Description 

rf-(e,K)€/ 

rty:/  I"  (j/-l  =  e)=^^(j/.2  =  ey)  £)18 

T\-u=f{e)  {y^<peU<t>u) 


ri-  e  €  s 

r  h  ^  a:  :=  e)  Q  P 
rfy  :  s\-  X  :=  y)  P  y  =  e 
^[-e  =  ^J,x:  s\P 


D19 


Editor’s  note:  IF  THEN  ELSE 


Substitution 

Tti  i;  D7b{ab  n  (/>u  =  0) 

r  h  u  =  ^  6p  ©e 


r  h  V  =  ^  X  :=  u)  oe 
rjx  ~  u\~  V  e 


Usedef{x  ^  ^v) 


F.3.6  Schema  calculus 


r  I-  tf  e  [a:i  :  5i;  ■ .  ■ ;  a:n  :  gn]_  BindProd 
r  I-  u.xi  e  Si  A  ...  A  u.Xn  6  s„ 


ri-6e5  \-\b)  QP 
T\-be[S\P] 


t4-?  SchemaMem 


r  F  O)  ®  ^ 

rh  6e  5 


t|  I>14(wf5) 


r  I-  ^  6}  ©  [6o5] 

fVbTS 


ti  D15(wf  6) 


r  1 — '  ^  ©  5 

T  \~  b  £  S 


ti  SNot{vffS) 


ri-O}  QS  A^b)  QT 
Th-beiS  AT) 


ti  SAnd{vffS  A  T) 
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r  h  ^  6)  ©  5  V  O) 
r  I-  6  e  (5  V  T) 


—  t;  5or(wf  5  V  T) 


ri-^6)  QS=^ib)  QT 

r  h  6  €  (5  r) 


t4-  SImp{vffS  T) 


ri“^6)  ©r 

r  h  6  e  (5  ^  T) 


t;  5/#(wf  5  T) 


ri-aS'*^)  ®^t4-  S’Earisis 

ri-6635*T  {(pT  0  {ab  U  aS))  =  0 


T\-yS*ib}  QT  ^iSAll 
r\-  b  eVS  •  T  {4>T  r\  (ab  U  aS))  =  0 


Editor’s  note:  SHIDING.  SPROJECTION,  SCOMPOSITION,  SDECORATION,  SSUBSTITUTION. 
SUNIQUEQUANT  _ 
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F.4.3  Predicates 

rheigr  rf-e2gr 
r  h  ei  =  62  y/ 

rhegT  Fhsg  Vt 

r  h  6  6  S  y/ 


r  h  true  y/ 


T3a 


r  h  false  y/ 
T\-P  y/ 


T3b 


T4- 


rh-F  ^/ 

yy-p  V  T\-Q  V 

T\-PAQ  y/ 

yy-p  V  y\-  Q  y/ 

rhP  V  Q  y/ 

THF  ^/  y\-Q  y/ 

y\-P=i^Q  y/ 

yy-p  y/  TK?  7 

yy-p-!^  Q  y/ 

r  1-  e  g  T  rj:a:  :=  e  h  P 
r  h  ^  a;  :=  e)  ©P  y/ 


T4A 


T4V 


TA-^ 


re 


r  h  5 ::  ytsy-p  y/ 
yy-ys»p  y/ 


Tzev 


yy-3S»p  y/ 


r  I-  5  ::  rt5  h  P  y/ 

r  h  3i  5  •  P  y/ 


r363i 


r  1-  5  g  pil(ari  Ti, . . . ,  a:„  T„) 

ri-xigri  ...  rt-a;„gT„ 


yy-s  y/ 


T33 


yu  b)  y-p  y/ 
ri-  V 


T32a 
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Editor’s  note:  NUMBERL,  STRINGL 


rt[a:]  T  h  5  g  Vt'  rt[a:]t  T  H  y  g  r 
Tt[x]T  h  y[s]  g  {I3x  ^  tYt 


rt[a:]  h  I  g  V{l5x) 


rheigr  ...  rhcngr 
r  h  {ei,...  ,e„}  gPr 


rt5  h  e  g  r 
r  I-  {  5  •  e  }  g  Pr 


r  h  5  g  'Pr 

ri-Psgp(pT) 


r  h  ei  g  Ti 


r  h  e„  g  T„ 


rh  (ei,...,e„)  gX(Ti,...,T„) 


r  h  Si  g  Vti 


r  i~  Sji  g  Ttji 


r  h  Si  X  •  •  •  X  s„  g  PX(ti,  . . . ,  r„) 


ri“  6gX(’r’l)..-5Tlj...j  Tjx ) 

r  h  e.i  g  Tj 


ri5(l  <i<n) 


r  h  ei  g  Ti 


I-  e„  g  T„ 


ri“  ^  Xi  : —  eif .  * .  j  Xfi  : —  e^  ^  g 


r  h  Xi  g  Tl  •  •  ■  r  h-  Jn  g  Tn  TiA 

T\-9S  gS(a;i~»Ti,...,a;„~>T„)  aS={a;i,...,x„} 
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r  h  6  S  S(a:i  Tl, . . .  ,Xn  Tn) 

r  1-  b.xi  %  Ti 


r28(l  <i<n) 


r\- f  %VX{t',t)  ri-egr^ 
ri-/(e)gT 


T\-ss'Pt  x:s\-PV 
T  \-  iJ,x  :  s  \  P  iT 


Editor’s  note;  IF  THEN  ELSE 


r  h  &  g  s(3;i n, . . . , 

xi'-^Ti,...,xn'^T„)  rsi 

b)  \-XiZTi  (1  <  t  <  n) 


b)  F  e  g  r 
r  I-  bee  g  r 


T326 


r  h  s  svz{xi 

Xi'^Ti,...,Xn'^T„)  T35 

rt5  h  g  r<  (1  <  i  <  n) 

r|3:  :=  »  I-  e  g  T  _  <  i  <  n) 

r  h  i  X  :=  u}  ee  2  T 


F.4.5  Schema 
rhSiiPri  •  •  •  r  h  Sn  g  ^Tn 
r  h  :  Si;  •  •  • ;  x„  :  Sn  g 

Pl^(xi  TI, . . .  ,  In  Tn) 


r  h  S  2T  S  i-  P 
rhS I  Pgr 


T38 


rh  ggr 

ri--5gT 


r39 


r  h  S'  g  psg  I-  r  g  PS.; 
r  h  s  A  r  g  VE(g  u  ?) 


r40A 


rhSgPSg  FTgPSc 

rhS  V  T2PE(eU<;) 
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Editor’s  note:  SPROJECTION  ,  SHIDING 


r  1-  5  g  rac  I-  T  g  VEq 


ri-v5.  rgra(e\\?) 


r  h  5  g  I-  T  g  V^Q 

ri-35.  rgPE(^\\0 


rhggm  hrgpsg 

rh3i5.  rgps(e\\c)  1 


Editor’s  note:  SCOMPOSITION,  SDECORATION,  SSUBSTITUTION 
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F.5  Free  variables  and  alphabets 
F.5.1  Paragraphs 


F.5.2  Predicates 


4>[x] 

<t>P 

<t>s 

(f>{x  :  s) 
<l){x  :=  e) 
4>{[x]T) 


0 

<f>s 

<t>e 

<l>T\{x} 

^IIi  U  (<^112  \  alli) 


a[i] 

aP 
aS 
a{x  :  s) 
a{x  :=  e) 
a(MT) 
a(nitn2) 


0 

{x} 

{^} 

aT 

alli  U  aTL2 


$(e  G  s) 

= 

(pel}(j)s 

$(e  =  v) 

= 

(j>eU4>v 

$true 

= 

0 

$false 

0 

$(-nP) 

$P 

$(P  A  Q) 

= 

$p  u  $<5 

$(P  V  Q) 

= 

$p  u 

$(P  =»  Q) 

= 

$P  u  $Q 

$(P  Q) 

= 

$PU$(? 

$V5  •P 

<^5U($P  \  aS) 

$35  .P 

= 

<A5U($P\a5) 

$3^5  •P 

= 

<^5U($P  \  aS) 

$(5) 

== 

aS  U  ^5 

a:  ;=  e)  ©  P 

= 

^6eU($P\{x})  (?) 

$(^  b)  ©P) 

$P  \  ab  (?) 
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F.5.3  Schemas 


^[^1  •  *  *  *  )  •  ^n] 

^[5  I  P] 

<I){S  A  T) 
(/>(5  V  T) 
ct>{S  T) 
4>{S  T) 
^(5Proj  T) 
. . .  ,  In]) 

^(V5*T) 
0(3  5*  T) 
^(3i5.T) 

^(5§r) 

^(5’) 

(/.(Jos') 

Qr[ll  I  • .  *  )  In  *  ^n] 

a[5  I  P] 
a(-.5) 
a{S  A  T) 
a{S  V  T) 
a(5  ^  T) 
a{S  ^  T) 
a{S  Proj  T) 

a(5\[ii,...,in]) 

ai'iS  •  T) 
a{3S  •  T) 
a(3i  5  •  T) 
a{S[xi/yi,...,Xn/y„]) 
a(5sr) 
a{S^) 
aiboS) 


=  <t>{sl)\J---U<t){Sn) 
=  (t>SU{^P\aS) 

=  <f>S 
=  <^5u<^r 
=  (j>SU(l)T 
=  (pS[J<l)T 
=  0S'u</>r 


=  ^i?u<^r 
=  (j)SU(j)T 
=  <f)SU(l>T 


—  j  •  •  •  j  ^n} 

=  a5 
=  aS 
=  a^UaT 
=  aS'UaT 
=  aSUaT 
=  a5UQ;T 


=  aT\aS 
=  aT\aS 
=  aT\aS 


=  {a;i,...,rcn} 
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F.5.4  Expressions 


^{x) 

<t>{x[y]) 

<j){S  •  e} 
^(P  s) 

0(^1)  •  •  •  >  ^n) 
(l){si  X---XSn) 

(t>l\  :=  ei,...,Xn  :=  e„  D 

<f,{dS) 
(f>{b.x) 

me)) 

</>(/i  S  •  e) 
0(if  P  then  ei  else  62  fi) 
<^(6oe) 
<f){{  X  :=  wf  oe) 


{4 


0(ei)U-"U^(e„) 
4>SLl{<l)e  \  aS) 

<f>is) 

<t){ei)Li  •  •  •  U(l){e„) 
<f>{si)U---U<j>{sn) 

^(ei)  U--  -  U^(e„) 
$5 

m  (?) 

<f>f  U 

<j>S  U  $(ei  \  aS) 

<j)e\ab  (?) 
4>{u)U<l>{e)  \  {x}  (?) 
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F.6  Substitution 
F.6,1  Predicates 

6  0(e  =  w)  =  6oe  =  6ow 
6  ©  (e  G  5)  =  boe  G  beu 
b  0  true  =  true 
6  ©false  =  false 
b  Q  P  =  “>6©P 
bQ{P  A  Q)  =  bQP  A  bQQ 
bQ{PWQ)  =  bQPV  bQQ 
bQ  {P  ^  Q)  =  b  Q  P  b  Q  Q 
bQ{P^Q)  =  bQP^bQQ 
When  ab  D  ^PCaS: 

6©V5#P  =  V6g5#P 
6©35*P  =  36g5*P 
b  Q3^  S  •  P  =  3j^  boS  •  P 
When  a6  n  a5  n  $P=  0  and  a5  fl  <f)b—0: 
bQWS^P  =  WboSmbQP 
6©35«P  =  3  6g5  •  6  ©  P 
6©3i5#P  =  3i6g5#6©P 
When  ab  r\  aS  ^  0: 

bQS  =  [6g5] 

When  wf6: 

bQS  =  b  Q  [6g5] 

^  2/  :=  -y)  ©  (^  2/  :=  P)  =  ^  y  ~  i  y  :==  v)  ou)  Q  P 
^  a:  :=  ©  (^  y  :=  u}  P)  = 

^  y  :=  ^  x  :=  v)  gw}  0  a:  :=  w)  ©  P) 
where  y  ^  (l>v 
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F.6.2  Schema  predicates 


6©[5|F]  = 
bQ[-<S]  = 
bQ[S  AT]  = 

6  ©  [5  V  T]  = 
bQ[S^T]  = 
bQ[S^T]  = 
bQiSProjT]  = 

6  ©  •  •  •  )  ®n]  = 

When  aSr\{^bQT  U  0:6) 
6©[VF.T]  = 
6©[3F*T]  = 

6  ©  [3^  5  •  T]  = 

b(D[S[xi/yi,...,Xn/y„]]  = 

6©[5gT]  = 
6©[5’]  = 
bi  ©  [boS]  = 


6  0  5A60P 
—tb  ©  S 

bQS  AbQT 
605  V  60  T 
6  0  5  ^  6  ©  r 
6  ©  5  6  0  T 


=  0: 

V6o5#60T 
3  6o5  •  b  Q  T 
3j  boS  •  6  ©  T 
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F.6.3  Expressions 

box  =  b,x  when  x  £  ab 
box  =  X  when  x  ^  ab 
60a;  [y]  = 
boi  = 

6o{ei,...,en}  =  {boei,,..,boen} 

When  ab  D  (peCaS: 

bo{S  •  e}  =  {  boS  •  e  } 

When  ab  fl  aS  fl  <f>e=^  0  and  aS  D  (j)b=^0: 
bo{S  #6}  =  {boS  •  boe} 

6gP  5  =  P  bos 

b0((ei,...,e„))  =  (boei,...,been) 
be(si  X  ■■■  X  Sn)  =  bosi  X  ■  ■  ■  X  bes„ 
bo(e.i)  =  (beej.i 
bo^  xi  :=  :=  e„  1}  = 

^  xi  :=  boei,  ...,x„:=  bee„} 
boeS  =  6boS 

when  abr\aS  =  0 
boes  =  b 

when  ab  =  aS 
biob.x  =  {bieb).x 
b0{f(e))  =  (6o/)(6oe) 
bo{iJ,S»e)  =  Agh.  Look  at  Stephen’s  Fig  9.1 
6o(if  P  then  ei  else  62  fi)  = 

6io(6©e)  = 

^  a;  ©(^  x  :=  u)  ®e)  =  ^  a;  ;=  ^  a;  :=  v)  ©u)  ©e 

^  y  ©(^  X  :=  u\  ®e)  =  ^  a;  :=  ^  y  :=  ©u^  © 

y  :=  u)  ©e) 
when  X  ^  <j>v. 
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F.6.4  Schema  expressions 


6©[5  I  P] 
be[S  I  P] 


i»o[-'5] 
bo[S  A  T] 
6o[5  V  T] 
be[S  T] 
bo[S  ^  T] 
b@[S  Proj  T] 
bQS\[xi,...,x„] 
6g[V5*  T] 
6o[35.  T] 
6o[3i  S»T] 
b@[S[xi/yi,...,Xn/y„]] 
be[S  §  T] 
be[S^] 
6io[6g5'] 


[beS  I  6  ©  P] 
when  abr\aS  =  0 
[boS  I  P] 

when  ab  n  ^PCaS 
[-iJoiS] 

[beS  A  boT] 

[boS  V  6©T] 

[boS  =?►  boT] 
[beS^boT] 


\^boS»boT] 
[3  605  •  beT] 
[3i  beS»boT] 
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F.7  Provisos 

(«5  =  s) 


eis  judgements 


r  h  P  T'haS  = 

r'  h  p' 


s 


r  h  =  a;  r  H  a5  =  2  VXS\-<l>P  =  y 
ri-0V5.P  =  a;U(y\2) 

□ 


Z  Notation  Version  1.1  30th  June  1995 


219 


G  References  —  Informative  Annex 


Notes  on  this  section  of  the  Z  Standard 

Section  title:  References 

Section  editor;  John  Nicholls 

Source  file;  infref.tex 

Most  recent  update:  29th  June  1995 

Formatted:  3rd  July  1995 


References 

[1]  Abrial,  J-R.,  “A  Course  on  System  Specification,”  Lecture  Notes,  Programming  Research 
Group,  University  of  Oxford,  1981. 

[2]  Bowen,  J.  R,  ‘‘Select  Z  Bibliography,”  available  from  newsgroup  comp. specification. z. 

[3]  Brien,  S.M.,  Gardiner,  P.H.B.,  Lupton,  P.J.,  Woodcock,  J.C.R,  “A  Semantics  for  Z,”  in 
preparation,  1992. 

[4]  Brien,  S.M.,  Nicholls,  J.E.,  Z  Base  Standard  Version  1.0,  Working  Draft  of  the  Z  Standards 
Panel.  Also  published  as  Technical  Monograph  PRG-107,  Oxford  University  Computing 
Laboratory,  1992. 

[5]  BSI  Standard  BS  0  :  Part  1  :  1981,  A  standard  for  standards.  Part  1.  Guide  to  general 
principles  of  standardization.^  British  Standards  Institution,  1991. 

[6]  BSI  Standard  BS  6154,  Method  of  defining  syntactic  metalanguage^  British  Standards 
Institution,  1981. 

[7]  Enderton,  H.B.,  Elements  of  set  theory^  Academic  Press,  1977. 

[8]  Gardiner,  P.H.B.,  Lupton,  P.J.,  Woodcock,  J.C.R,  “A  simpler  semantics  for  Z,”  in  J.  E.  Nicholls 
(ed),  Z  User  Workshop,  Oxford  1990,  Proceedings  of  the  Fifth  Annual  Z  User  Meeting, 

Springer- Verlag,  1991. 

[9]  Goldfarb,  C.  F.,  The  SGML  Handbook,  Clarendon  Press,  Oxford,  1990. 

[10]  Hamilton,  A.G.,  Numbers,  sets  and  axioms,  Cambridge  University  Press,  1982. 

[11]  Hayes,  1.  J.,  (ed.).  Specification  Case  Studies,  Prentice-Hall  International,  1987. 

[12]  ISO  (International  Organization  for  Standardization),  ISO  8879-1986  (E)  Information 
Processing  -  Text  and  Office  systems  -  Standard  Generalized  Markup  Language  (SGML), 
Geneva:  ISO,  1986. 

[13]  Jones,  C.  B.,  Software  Development-A  Rigorous  Approach,  Prentice-Hall  International,  1980. 

[14]  Jones,  C.  B.,  Systematic  Software  Development  using  VDM,  Prentice-Hall  International,  1986. 


220 


Z  Notation  Version  1.1  30th  June  1995 


REFERENCES 


[15]  King,  S.,  S0rensen,  1.  H.,  Woodcock,  J.C.R,  “Z:  Grammar  and  Concrete  and  Abstract  Syntaxes 
(Version  2.0),”  Technical  Monograph  PRG-68,  Programming  Research  Group,  University  of 
Oxford,  1988. 

[16]  Lalonde,  W.R.,  Des  Rivieres,  J.,  “Handling  Operator  Precedence  in  Arithmetic  Expressions  with 
Tree  Transformations,”  ACM  Transactions  on  Programming  Languages  and  Systems,  Vol  3,  No 
1,  January  1981. 

[17]  McMorran,  M.A.,  Nicholls,  J.E.,  “  Z  User  Manual,”  Technical  Report  TR12.274,  IBM  Hursley 
Park,  1989. 

[18]  Morgan,  C.  C.,  “Schemas  in  Z:  a  Preliminary  Reference  Manual,”  Programming  Research 
Group,  University  of  Oxford,  1984. 

[19]  Nicholls,  J.E.,  “Domains  of  application  for  formal  methods,”  in  Proceedings  of  Z  User 
Workshop,  University  of  York,  Workshops  in  Computing,  Springer- Verlag,  1992. 

[20]  Sennett,  C.  T.,  “Syntax  and  Lexis  of  the  Specification  Language  Z,”  RSRE  Memorandum  No. 
4367,  1990. 

[21]  S0rensen,  1.  H.,  “A  Specification  Language,”  in  Program  Specification  (J.  Staunrup,  ed.).  Lecture 
Notes  in  Computer  Science,  vol.  134,  Springer- Verlag,  1982. 

[22]  Sperberg-McQueen,  C.M.,  Burnard,  Lou  (editors),  Guidelines  for  Electronic  Text  Encoding  and 
Interchange,  TEI  P3,  Text  Encoding  Initiative,  Chicago,  Oxford  April  8,  1994. 

[23]  Spivey,  J.  M.,  Understanding  Z:  a  specification  language  and  its  formal  semantics,  Cambridge 
University  Press,  1988. 

[24]  Spivey,  J.  M.,  The  Z  notation  -  a  reference  manual,  Prentice-Hall  International,  1989.  (2nd 
edition,  1992). 

[25]  Stoy,  J.E.,  Denotational  semantics:  the  Scott- Strachey  approach  to  programming  language 
theory,  MIT  Press,  1977. 

[26]  Sufrin,  B.  A.,  “Formal  Specification:  Notation  and  Examples,”  in  Tools  and  Notations  for 
Program  Construction  (D.  Neel,  ed.).  Cambridge  University  Press,  1981. 

[27]  Sufrin,  B.  A.,  (ed.),  “Z  Handbook,  Draft  1:1,”  Programming  Research  Group,  University  of 
Oxford,  1986. 

[28]  Woodcock,  J.  C.  P.,  “Structuring  Specifications  in  Z,”  Software  Engineering  Journal,  Vol  4,  No 
1  (January  1989). 

[29]  Woodcock,  J.C.P.,  Brien,  S.M.,  “W:  a  logic  for  Z,”  in  J.  E.  Nicholls  (ed),  Z  User  Workshop, 

York  1991,  Proceedings  of  the  Sixth  Annual  Z  User  Meeting,  Springer- Verlag,  1992. 


Z  Notation  Version  1.1  30th  June  1995 


221 


